# Introduction to Mission Control
Welcome to an Introduction of Mission Control. This guide is meant to give you an overview of the functionalities Mission Control offers and its role in the Zaikio platform.
# What is Mission Control?
Mission Control is the central data exchange and process monitoring station for the Zaikio platform.
# What does Mission Control do?
Mission control provides an API that allows you to store orders, job specifications (including binary file references), logistics information, and all shop floor specific data (including impositions, worksteps, material requirements, production schedules, etc.). Other apps can then use the same API to retrieve that data. Mission Control is based on a persistent database, so other apps can query the data you provide at any time (as opposed to being a mere forwarding architecture). Mission control will also check all incoming data for compliance with our standard data model, as well as plausibility. Thus we ensure that connected apps can trust that all information retrieved from Mission Control is compliant and valid from a logical point of view.
In summary, Mission Control's core functions are:
- Data exchange between connected apps regarding orders, job specifications, logistics, and all required data for shop floor operations
- Action triggering by sending events to all connected apps whenever data changes, so that the apps can react
- Process monitoring and shop floor awareness of equipment (IoT) as well as end users through the API and the UI
# What does Mission Control not do?
Mission Control's core functions are data exchange and progress tracking. As such, it is designed solely as a data repository. Mission Control will not generate data by itself. It will not create orders or job specifications, nor does it know how to find files or generate production schedules. It does, however, provide the required data models and API interfaces for third party apps to create that information. In essence, Mission Control is completely reliant on third party applications and data to make it come to live.
# Dissecting Mission Control – the data parts
Mission Control's data model covers a wide range of topics in order to facilitate an end-to-end process for printers. To make the data model and API more accessible we have divided it into the following six components:
# Business API
This part covers everything related to the order of printed goods and the business transaction that lies behind it, such as customer information, payment information, invoicing information, etc. The order is loosely coupled to products via its line items, but apart from this we keep the two independent.
Further reading on the Business API coming soon.
# Job Specification API
This part covers everything related to a single printed job. Since Mission Control's function is that of a data exchange, it doesn't know about templates, instead it requires a complete job specification for every single job produced. Job specifications cover all information necessary to describe a printed item: job parts including their layout (both boxed and path-based), colours, desired substrates, as well as finishings and their application, raw material requirements and confectioning (packaging during production).
Further reading on the Job Specifications API coming soon.
# Estimation API
The Estimation API provides a full set of data storage and tools to assist the process of estimating or quoting on potential Jobs.
# Production Strategy API
The Production Strategy API provides an extensive data model for describing how Jobs should be produced. The
# Logistics API
This part covers how products and other materials are picked, packed and dispatched to their destinations, including carrier and parcel information, manifests, shipping lists and the like. Throughout Mission Control we strictly separate confectioning (applying packaging during the production process, which is part of the job specification) and commissioning (applying packaging after the production process and are thus part of the logistics API). Further reading on the Logistics API coming soon.
# Shop Floor API
This part covers how products are made on the shop floor. It provides interfaces and data models to store information regarding worksteps, their durations and phases, planned and actual costs, executions and schedules, intermediate products (including their layouts) coming out of worksteps and connecting worksteps together, thus building a process network, as well as artwork references, and material demands. Further reading on the Shopfloor API coming soon.