What runs, where, and what happens when things fail.

AI runtime boundaries.

AI services run in the customer-controlled deployment boundary unless a customer explicitly chooses a hosted review flow. Model outputs are advisory evidence: signatures, manifests, HSM counters, and customer approval policy remain authoritative.

Topology.

                    // 3DCIPHER runtime, deployed at a customer site

  +--------------------+         +--------------------+         +--------------------+
  |  slicer host       |  bundle |  printer host      |   sig   |  customer manifest |
  |  - signed slicer   | ------> |  - 3dc daemon      | ------> |  - append-only log |
  |  - operator login  |  v3     |  - Vault3D HSM     |   v3    |  - signed Merkle   |
  |  - slice + attest  |         |  - firmware signed |         |  - posture publish |
  +--------------------+         +--------------------+         +--------------------+
                                          |                                |
                                          |  HSM-signed posture, 1/min     |
                                          v                                v
                                 +--------------------+         +--------------------+
                                 |  customer console  | ------> |  ceremony anchor   |
                                 |  - SAML/OIDC IdP   |  pull   |  - root pin        |
                                 |  - posture view    |         |  - verifier-CLI    |
                                 |  - audit package   |         |  - mirror agreement|
                                 +--------------------+         +--------------------+

Four plane shapes: AI evidence plane (review and anomaly scoring), slicer plane (work originates), printer plane (work is signed), customer plane (work is archived and audited). 3DCIPHER infrastructure is the ceremony anchor only — we do not hold customer keys, customer manifests, or customer telemetry.

The signing path.

One bundle, from operator click to archive. The numbers are p99 from production fleet measurement; the median is approximately 0.55× each step.

1. Slicer attests its own build (~4 ms). The signed slicer binary publishes its build hash and slicer-attestation key. Verifier-CLI cross-checks against the manifest.
2. G-code is canonicalised (~8 ms). The slicer emits canonical-form G-code (sorted comments, normalised whitespace) so identical inputs produce identical bundle hashes.
3. Operator binding is captured (~12 ms). The operator's IdP-issued session token is bound to the bundle; without it, the daemon refuses to sign.
4. Bundle is composed (~28 ms). G-code, slicer build hash, firmware hash, sensor envelope, operator token, machine-monotone counter. Composed as a canonical-form CBOR payload.
5. HSM signature is requested (~95 ms). The 3dc daemon submits the canonical CBOR digest to the printer's HSM. The HSM signs without the daemon ever seeing the private key.
6. Signature is verified locally (~10 ms). The daemon verifies the HSM signature against the printer's published public key before continuing — defends against HSM firmware misbehaviour.
7. Bundle is committed to the manifest (~22 ms). Append-only log; signed Merkle root recomputed.
8. Posture is updated (~4 ms). The printer's posture record is updated; the next posture publish (max 60s away) carries the new state.

End-to-end p99: 183 ms. Of which ~52% is HSM signature operation, which is by design — the HSM is the slowest step and the most security-critical.

Boot sequence.

What happens when a 3DCIPHER-equipped printer boots from cold.

T+0.0s   power on
T+1.2s   bootloader verifies firmware signature against manifest pin
T+1.4s   firmware loads; refuses to start if signature fails
T+1.5s   3dc daemon starts in verify-only mode (cannot yet sign)
T+1.8s   daemon pulls latest manifest; verifies against ceremony root
T+2.6s   daemon establishes session with printer-side HSM
T+2.9s   HSM challenge-response: daemon confirms HSM is the enrolled HSM
T+3.1s   HSM-side health check: tamper switch state, key inventory, RNG self-test
T+3.6s   daemon enters sign mode; posture flips to active
T+3.6s+  first posture publish; subsequent every 60s

         # total cold-boot path: under 4 seconds to first signable state.

Key custody.

Three key tiers, with rotation cadence and ceremony scope.

Printer-side keys never leave their HSM. The HSM has no exfiltration interface; the cryptographic boundary is the HSM enclosure. Rotation of a printer-side key is a decommission-and-re-enrol of that printer.

Failure modes.

What goes wrong, and what the system does about it.

Manifest pull stale (network partition).

The printer-side daemon enters verify-only mode after the manifest TTL elapses (default 24 h, configurable 1–72 h). It can still verify past bundles but will not sign new ones. The posture record carries the stale-since timestamp. Remediation: restore network reach. RB-30.

HSM unresponsive.

The daemon retries with exponential backoff (4s, 8s, 16s, fail). On fail, the daemon transitions to fault mode; the printer is taken offline by the daemon (the print job will refuse to start). Customer console raises an alarm. Field intervention required. RB-31.

Signature verification mismatch (after HSM sign).

The daemon verifies every HSM signature before committing it. If verification fails, the bundle is not committed and the HSM is quarantined — we suspect HSM firmware misbehaviour. This is the only condition that escalates direct to on-call engineering. RB-32.

Operator IdP outage.

The daemon caches the most recent operator session for the IdP-configured TTL (default 8 h). After cache expiry, signing is refused. Customer-configurable per policy. RB-33.

Posture publish unreachable.

The daemon queues posture records locally (up to 7 days) and publishes when reach is restored. Signing continues. RB-34.

Ceremony root rotation in flight.

During a ceremony root rotation, both old and new roots are advertised in the manifest. The verifier-CLI accepts either for a 30-day transition window. No customer action required unless their integration hard-pins the old root.

SLOs.

We publish the SLOs we hold ourselves to. The aggregate posture endpoint exposes the live values.

What we expose to your monitoring.

3DCIPHER does not run an opaque control plane. Everything we observe about a customer's fleet, the customer can also observe.

• Prometheus metrics endpoint on the printer-side daemon: sign rate, sign latency histogram, HSM round-trip latency, manifest staleness, posture publish lag.
• Structured JSON logs on the printer-side daemon, with redaction guarantees for bundle contents (only hashes and identifiers, never the underlying G-code).
• Signed posture events over the manifest publish endpoint: machine-readable, intended for the customer's SIEM.
• Audit trail on the customer console: every operator action, every ceremony record, every rotation. Read-only from the console; exportable to your SIEM.