How is Qynetic architected?
Qynetic is built as a modular core that consumes normalised manufacturing events and entities regardless of their source, with safety boundaries between AI reasoning and physical control.
Multi-tenant hierarchy
Organisation → site → area → machine. A user may belong to several organisations and sites; nothing assumes one company, one factory, one machine type or one process.
Canonical manufacturing model
Machines, tools, programs, articles, characteristics, measurements, quality events, offsets, maintenance and more are modelled once, independent of vendor. Internal identifiers are UUIDs; external identifiers and provenance are kept separately.
Event envelope
Facts are carried in a consistent envelope: event id and type, tenant and site, source, entity, occurred-at and received-at timestamps, schema version, payload and metadata. Both timestamps are kept so ingestion lag is observable.
Connectors and Edge
Connectors translate vendor protocols into canonical events and run either in the cloud or in Qynetic Edge inside the factory network, which buffers during outages and connects outbound only.
Agents and Factory Director
Specialised agents (quality, APC, tooling, CIM, OEE, planning, maintenance) produce structured, evidence-backed recommendations over shared context; Factory Director prioritises them.
APC safety pipeline
AI reasoning → validated engineering algorithm → simulation → policy guardian → deterministic control → physical process → verification. The guardian is a pure, deterministic function whose default is to deny.
API-first
Qynetic is designed to expose a versioned API (/api/v1) whose contracts are independent of the database schema, with scopes, keys and webhooks.