Architecture
How is Qynetic architected?
Qynetic is a modular core that consumes normalised manufacturing events and entities regardless of their source, with specialised agents and modules on top, and 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. Sites own their time zone, locale and units.
Canonical manufacturing model
Machines, tools, programs, articles, characteristics, measurements, quality events, offsets and maintenance are modelled once, independent of vendor. Internal identifiers are UUIDs; external identifiers and provenance are kept separately.
Connectors and Edge
Connectors translate vendor protocols into canonical events and run 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 whose contracts are independent of the database schema, with scopes, API keys and webhooks.
Observability
Structured logging, health endpoints, ingestion-lag visibility and failed-event tracking are designed in from the start.
AI may reason. AI must not control machines.
- AI reasoning
- Validated algorithm
- Simulation
- Guardian
- Deterministic control
- Verification
Involves AI (recommends)Deterministic and testable
Anything outside authorised limits requires human approval. Values outside absolute bounds are rejected and cannot be approved. Control runs near the machine, so losing the cloud cannot create unsafe behaviour.
The event envelope
Every ingested or generated fact is wrapped in a consistent envelope, regardless of source:
- event_id / event_type
- Unique id and a type such as measurement.recorded
- tenant_id / site_id
- Which organisation and site own the event
- source / source_id
- Which integration, edge node, user or agent produced it
- entity_type / entity_id
- What the event is about
- occurred_at / received_at
- When it happened at the source and when Qynetic received it
- schema_version
- So payloads can evolve safely
- payload / metadata
- The data, plus provenance such as transformed and confidence
Be among the first to know
Qynetic is being built now. Join the waitlist and we will tell you when it is available.