Documentation

Everything we would want to read first.

Architecture, connectors, agents, envelopes, autonomy, the twin and the audit schema. Written for the process engineer, the OT lead and the change-control board — in that order.

Request documentation access

Start here

Getting started

01 Architecture overview
The three tiers — cloud or private control plane, fab-edge runtime, line tier — and the trust boundaries between them.
02 The autonomy model
Shadow, assist, bounded autonomy and supervised autonomy: what each gate requires, how it is measured and how it is withdrawn.
03 Action envelopes
Authoring, versioning and approving the bounds within which any agent may act on a tool.
04 Deployment
Fab-edge hardware sizing, cluster installation, network segmentation, SSO configuration and release pinning.

Connectors

Talking to the line

01 SECS-GEM / HSMS
Session setup, variable and event discovery, collection-event subscription, remote command mapping and fail-safe behaviour.
02 OPC-UA
Node discovery, subscription models, security policies and write-path constraints for tools exposing OPC-UA instead of SECS-GEM.
03 Vendor APIs
REST and gRPC integration patterns for bonders, aligners, inspection systems and testers with proprietary interfaces.
04 Inspection data
X-ray, CT, SAM and AOI ingestion by stream or monitored drop, including volume handling and retention.
05 MES, YMS and PLM
Lot, package, recipe, route and disposition context in; verified outcomes and dispositions back out.
06 Connector SDK
The interface contract for building a connector to a tool Chipira does not yet cover: telemetry, actions, envelopes and failure semantics.

Agents

Reference by capability

Reference

The action envelope

An envelope is a versioned, signed document owned by your process engineers. It is the single artifact that determines what any agent may do to any tool. Nothing executes outside it — not in an incident, not for support, not ever.

Security and governance

envelopes/bond-line4.yaml

id: bond-line4
version: 12
owner: process-integration@fab-kh-04
tools: [bonder-4a, bonder-4b]
autonomy: L3            # bounded autonomy
requires_twin: true

parameters:
  bond_force_n:      { min: 18.0, max: 24.0, max_step: 0.4 }
  bond_temp_c:       { min: 220,  max: 265,  max_step: 3 }
  dwell_ms:          { min: 400,  max: 1200, max_step: 50 }
  placement_offset_um: { min: -0.6, max: 0.6 }

conditions:
  - require: twin.verdict == "in_spec"
  - require: agent.rolling_accuracy >= 0.99
  - escalate_if: package.value_tier == "critical"

on_breach: { action: fail_safe_stop, notify: [shift-lead, process-owner] }
approved_by: [m.oyelaran, k.tanaka]

Illustrative envelope. Parameters and ranges are per line and per package family.

Autonomy levels

What each gate means

L1 · Shadow: Perception and proposals only. No write path exists. Used to establish a measured baseline against your current practice.
L2 · Assist: Proposals become one-click approvals in the console or via the API. Every approval and rejection is captured as supervised training data.
L3 · Bounded autonomy: Low-risk moves execute automatically inside the envelope, twin-validated, when the agent’s rolling accuracy holds above its gate.
L4 · Supervised autonomy: The closed loop runs the workflow, with humans on exceptions and escalations only. Reserved for workflows with a long measured record.
Revocation: Any level is withdrawn instantly by your organisation, and automatically when rolling accuracy falls below the gate’s floor.

Audit schema

Fields in every record

Field	Type	Description
ts	timestamp	UTC, millisecond precision, assigned at the edge.
agent	string	The capability that produced the record.
model	string	Immutable model release identifier, semantically versioned.
tenant	string	Site-scoped tenant. Records never cross tenants.
subject	object	Package, lot, tool and process step under evaluation.
grounding	array	Sources and locators cited by the proposal.
twin	object	Twin verdict and predicted outcome, where a twin was consulted.
envelope	string	Envelope identifier and version the action was checked against.
action	object	Proposed or executed action, with its autonomy level.
approval	object	Mode, approver and timestamp where a human was involved.
verified	object	Downstream verification result closing the loop.
immutable	boolean	Always true. Records cannot be edited or deleted.

Operations

Running Chipira day to day

Release management

Pinning, staged rollout, per-site channels and rollback. No production line receives an update it did not schedule.

Monitoring

OpenTelemetry traces, metrics and logs into your existing observability stack, plus agent-level accuracy and drift dashboards.

Evaluation

Golden datasets, LLM-as-judge scoring and regression gates that block a release when accuracy moves the wrong way.

Incident response

Fail-safe semantics, escalation routing, and a post-incident report grounded in the immutable audit trail.

Access reviews

Periodic review of roles, envelope ownership and approver lists, exportable for your compliance programme.

Model review

A scheduled review of agent accuracy, drift, exception rate and autonomy levels with your process owners.

Documentation that admits what the system cannot do is the only kind worth reading.

Process integration leadIDM back-end

Composite drawn from design-partner and industry conversations. Illustrative, not a customer endorsement.

Documentation

Access and scope

No. Architecture, security and API documentation is provided under NDA to prospective design partners and customers, because it describes deployment specifics we would rather discuss than publish.
Yes, to customers and design partners, alongside the connector interface contract and the audit schema.
Yes, and they should. The fail-safe and envelope-breach behaviour documentation is written specifically for that review.
Continuously — the product is pre-launch. Every documented interface carries a stability marker so you know what is safe to build against.

Start narrow, expand relentlessly

Land one workflow. Own the loop.

A Chipira engagement begins with a single wedge workflow, a shadow-mode baseline and one signed success metric. Everything after that is expansion.

Request a pilot See how we price