ATLAS/TRUST MODEL/LIFECYCLE SHEET L / 01

From arc bundle to arc install — ten stages of trust.

Every blueprint passes through ten stages before a consumer can install it. Each stage has an owner, a gate, and a design decision that anchors it. This is the story from the blueprint's point of view.

01
Author
OWNER: PUBLISHER
None — before metafactory is involved.
Namespace rules, blueprint types
CONTRIBUTOR JOURNEY →
02
Bundle
OWNER: ARC
Tarball must parse as valid manifest.
Manifest schema, SHA-256 integrity (L-Sign-1)
03
Publisher sign
OWNER: SIGSTORE
OIDC token chains to allowlisted issuer.
Keyless OIDC provenance (L-Sign-3)
SIGNING LEVELS →
04
Handover
OWNER: CROSS-REPO SEAM
Sigstore verify + identity match.
Intake seam contract (frozen)
HANDOVER SEAM CONTRACT →
05
Attribute gate
OWNER: METAFACTORY
Per-type required attributes, README, namespace.
Per-type validation, gate rules
ATTRIBUTE GATE →
06
Clean room
OWNER: METAFACTORY
L1 deterministic + L2 content + L3 sandbox.
Observer model, sandbox tiers, counterfactual runs
CLEAN ROOM →
07
Sponsor review
OWNER: METAFACTORY
Reviewer checklist, dual-control approval.
Human review required, sponsor model
08
Registry sign
OWNER: METAFACTORY
Sponsor approval + dual-control signing ceremony.
Ed25519 dual-control ceremony (L-Sign-2)
SIGNING LEVELS →
09
Publish
OWNER: METAFACTORY
Mechanical — once signed.
Content-addressed storage
10
Install + enforce
OWNER: ARC
4 independent crypto checks.
Install seam contract (frozen)
INSTALL SEAM CONTRACT →
R
Revocation
When a published blueprint turns out to be malicious — the 5-minute yank path. Dual-control signing, a new revocation list version, and propagation to every installed arc within its next poll window.
READ MORE: INCIDENT RESPONSE
BUNDLE INSTALL — REFERENCE MODEL
SHEET L / 04 BUNDLE INSTALL — REFERENCE MODEL (DD-111) USER consumer ARC CLI installer REVOCATIONS KV signed list REGISTRY metafactory R2 content-addressed SIGSTORE verify locally FILESYSTEM staging + final arc install @pub/bundle@1.0.0 Install protocol: freshness + revocation check GET revocations signed list + Rekor proof check list freshness GET bundle manifest manifest + refs + sigs verify bundle cosign + registry sig OK Per-reference fan-out: each ref is its own content-addressed fetch GET ref 1 by SHA-256 fetch from R2 ref 1 bytes verify ref 1 sigs stage ref 1 GET ref 2 by SHA-256 ref 2 bytes stage ref 2 ... ref N RENAME staging → final merge union capabilities installed (N refs) ALL-OR-NOTHING ATOMICITY Any reference failing verification rolls back the entire staging directory per DD-108 §3.3. A partial install is a bug. Revocation propagates by SHA-256 identity per DD-111, not by bundle identity.
BLUEPRINT LIFECYCLE — END TO END
SHEET L / 01 BLUEPRINT LIFECYCLE — END TO END PUBLISHER human author ARC CLI arc-owned SIGSTORE cosign + Rekor v2 INTAKE metafactory worker CLEAN ROOM L0 · L1 · L2 · L3 AUDIT LOG hash-chained + Rekor witness SPONSOR human steward REGISTRY R2 + KV + signer CONSUMER arc-owned installer arc bundle ./my-blueprint tar + SHA-256 cosign sign (keyless OIDC) Sigstore Bundle + Rekor UUID POST /intake/v1/submit Intake protocol: envelope + tarball + sigstore_bundle + rekor_uuid verify cosign + Rekor submission_id dispatch to attribute gate L0 attribute gate append gate decision L1 deterministic L1.5 composition (bundles) L2 content (open-source) L3 quarantine sandbox append layer outcomes report + checklist walk reviewer checklist dual-control if needed approval event sign request dual-control ceremony: registry-signer uses both key halves dual-control sign append register-sign publish revocation v+1 Install protocol: fetch · verify · merge GET /registry/v1/... tarball + X-Metafactory-* headers verify sigs + SHA-256 merge capabilities FOUR TRUST SEAMS 1. Bundle→Handover (Sigstore) · 2. Intake→Validation (attribute gate) · 3. Validation→Distribution (registry sign + audit log) · 4. Distribution→Install (cosign-verify + capability enforcement)
← Back to Trust Model Cryptographic signing →