0% read on this device
Browse the curriculum

Start Here

Vision

First Principles

Operating Model

Domain Model

Agent Factory

Runtime Architecture

AI Engineering

Autonomous Workflows

Verification & Delivery

Factory Platform

Quality Engineering

Security & Governance

Case Studies

Labs

Interview Practice

Research Journal

Reference

Curriculum/Domain Model/A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
Domain Model4 min readchapterQuick Read

Factory System Inventory, Classification, and Lifecycle

Maintain one accountability record for each material autonomous delivery system without copying its subordinate registries.

Status: Review readyRisk: criticalLifecycle: intent · plan · execute · verify · deliver · learnContent reviewed 2026-08-30Maturity guide →
Claim boundaryThis is curriculum guidance. It does not by itself prove a production implementation.
architecture mode

A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.

4. State model and commands

CommandAuthorized decision ownerRequired evidenceInvalid when
ApproveBusiness, engineering, security, and assurance owners by riskPurpose, architecture, risk, tests, controlsCritical fields or owner acceptance missing
ActivateSystem owner plus release policyQualified version and current proof packageReview expired or dependency revoked
RestrictControl owner or incident authorityReason, reduced ceiling, affected scopeRequested ceiling is broader than current
QuarantineEmergency authorityIncident or credible control failureNever blocked by ordinary change windows
DeprecateSystem and capability ownersReplacement or exit plan, noticeActive dependents have no disposition
RetireSystem owner and operationsTraffic stopped, grants revoked, records retainedActive work or unresolved downstream effect exists
DeleteData ownerRetention satisfied, deletion receiptLegal, incident, or audit hold exists

Every command carries actor identity, expected record version, reason, idempotency key, policy decision, and resulting event. Compare-and-set updates prevent stale approval from overwriting a containment action.

6. Failure, recovery, and observability

FailureDetectionContainmentRecovery proof
Orphaned ownerIdentity directory reconciliationBlock promotion and new grantsAccepted replacement owner
Stale registry referenceVersion-resolution checkFreeze affected workflowRe-resolved manifest and regression tests
Hidden downstream actionEgress and tool-call comparisonQuarantine capability and affected systemsUpdated boundary map and side-effect test
Expired reviewDue-date monitorRestrict autonomyCompleted review with decision record
Deletion mismatchRegistry and storage reconciliationHold closure and notify data ownerDeletion receipts across all governed stores

Emit state-change events with correlation identifiers. Measure inventory completeness, overdue review, unresolved owner, stale reference, exception age, time to containment, and time to verified retirement. Inventory data is classified and access-controlled; it often reveals sensitive architecture.

8. Tradeoffs and alternatives

A spreadsheet can start a small inventory but weakens referential integrity, event handling, and policy enforcement. A graph improves dependency and blast- radius analysis but does not replace authoritative registry ownership. Begin with one record API and explicit references; add graph projections only when measured review or incident needs justify them.

External review

Review this chapter.

Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.

  • Claim
  • Boundary
  • Failure
  • Evidence