Dark Factory Reference Architecture

Purpose

Dark Factory creates governed environments in which increasingly capable autonomous systems can safely create value for people, organizations, and society.

Its purpose is not to constrain intelligence. It governs the environment in which intelligence acts: authority, context, capabilities, evidence, consequences, evaluation, promotion, recovery, and accountability.

This document is the canonical system map for the repository. Principles define the durable invariants. Schemas define portable artifacts. Patterns describe implementation strategies. Evaluations attempt to falsify claims. Conformance profiles state what a deployment must prove for a bounded scope.

Architectural Scope

Dark Factory governs the lifecycle from human or event intent through value and outcome evidence:

intent
  -> governed goal and authority
  -> package construction
  -> qualification
  -> target projection
  -> authorized execution
  -> external consequences
  -> evidence and outcomes
  -> remediation, promotion, rollback, or retirement

Dark Factory does not prescribe a model architecture, inference provider, agent framework, identity product, tool protocol, memory store, deployment platform, or user interface. Implementations may replace any of these while preserving the required governance properties and producing comparable evidence.

See the system context diagram.

Architecture Layers

Layer	Purpose	Repository source
Purpose	Defines why governed autonomy exists and whose value matters.	Root README.md and this document
Principles	States invariants intended to survive technology change.	/principles
Reference architecture	Defines components, planes, responsibilities, and trust boundaries.	This document and /diagrams
Protocols and schemas	Defines portable, machine-readable artifacts and evidence.	/schemas, /contracts, /manifests
Patterns	Describes reusable implementation strategies and failure modes.	/patterns
Evaluations	Attempts to falsify behavioral and governance claims.	/evaluations
Conformance profiles	Selects requirements for a bounded deployment and risk class.	/docs and future profile artifacts
Implementation evidence	Records what a particular implementation actually demonstrated.	External run evidence and implementation profiles
Research findings	Refines or falsifies architectural assumptions.	Research-cycle and challenge documents

An implementation result may improve any layer, but no single implementation is architecture source truth.

Core Actors

Principal

A person, organization, event authority, or governed system that originates a goal and supplies authority. A principal is accountable for the authority it delegates but is not assumed to approve every action.

Governance Authority

The authority that defines policy, approves changes to governance, authorizes promotion, and establishes the terminal trust root. It must remain distinct from the artifact seeking promotion.

Factory Control Plane

Transforms accepted goals into versioned packages, contracts, evaluation plans, and target-neutral deployment intent. It coordinates construction and remediation but cannot manufacture qualification evidence.

Qualification Plane

Runs deterministic checks, held-out evaluations, adversarial suites, and qualified semantic evaluators. It produces bounded verdicts; it does not mutate the evaluated package.

Projection Plane

Compiles canonical packages and contracts into target-specific configuration. A projection is derived and must never silently add authority or become package source truth.

Orchestration Substrate

The trusted execution base that assembles context, instantiates workloads, enforces contracts, mediates tools and delegation, applies resource limits, captures independent observations, and enters safe states. It is governed out-of-band from the cognition artifacts it executes.

Cognition Artifact

The autonomous decision system operating inside a contract. It may reason, plan, synthesize, delegate, or act, but cannot authorize its own expansion, qualify itself, promote itself, or redefine the substrate.

Tool or External System

A capability with an explicit interface and consequence model. Consequential tools must verify runtime authority rather than trust natural-language claims of authorization.

Evidence Consumer

An operator, verifier, auditor, target, or other implementation that evaluates whether evidence is authentic, complete, applicable, and sufficient for a claim.

Outcome Stakeholder

A person, organization, community, or system affected by the result. Outcome stakeholders may differ from the principal and must be represented when value or harm crosses the principal's boundary.

Architectural Planes

Intent and Authority Plane

Captures the goal, success conditions, prohibited outcomes, principal, delegated authority, acceptable autonomy, and required oversight. Missing material intent is returned to the principal rather than invented.

Factory Plane

Constructs canonical packages and derives contracts, role topology, tool and memory requirements, evaluation obligations, and target-neutral behavior.

Qualification Plane

Separates four evidence classes:

1. Structural conformance.
2. Deterministic runtime evidence.
3. Repeatable semantic evaluation.
4. Field outcome and value evidence.

Semantic judgment cannot erase deterministic failure. Qualification remains bound to package, policy, target, executor tuple, evidence set, and time.

Runtime Control Plane

Issues or verifies workload identity, assembles governed context, narrows delegated authority, mediates actions, enforces budgets, captures receipts, and executes degraded-mode, quarantine, compensation, and emergency-stop policy.

Evidence Plane

Maintains lineage, receipts, attestations, evaluation observations, qualification verdicts, promotion decisions, and outcomes. Evidence must state its producer, subject, scope, authority, ordering, and invalidation conditions.

Value and Learning Plane

Compares intended and observed outcomes, including safety, quality, human effort, economic value, organizational acceptance, and external effects. It proposes remediation or architectural learning but cannot silently change production policy.

Canonical and Derived Artifacts

Artifact	Canonical status	Authority
Accepted goal	Canonical intent	Principal and governed intake process
Package	Canonical deployable definition	Factory process under governance
Governance contract	Canonical authority and behavior envelope for its stage	Governance authority
Evaluation plan	Canonical coverage obligation for a package version	Goal-derived qualification policy
Target projection	Derived	Projection plane
Runtime session state	Generated	Runtime only; never reusable source truth by default
Tool receipt	Evidence	Tool or independently observing substrate
Lineage record	Evidence	Runtime/evidence plane
Evaluation observation	Evidence	Authorized evaluator
Qualification verdict	Derived evidence conclusion	Qualification plane
Promotion decision	Governance event	Authorized promotion authority
Deployment outcome	Evidence	Runtime, operator, or outcome collector
Research conclusion	Bounded interpretation	Research process; never a universal fact by default

The artifact lifecycle diagram shows the transitions and invalidation paths.

Trust Boundaries

The architecture assumes no universal trusted actor. Trust is divided by responsibility and verified at boundaries.

1. Principal boundary: natural-language intent becomes structured goal and authority; ambiguity must not create implied permission.
2. Factory boundary: builders may propose packages but cannot issue their qualification.
3. Evaluation boundary: fixtures and evaluators must remain protected from the evaluated artifact and from unauthorized mutation.
4. Promotion boundary: promotion authority is external to the candidate.
5. Runtime boundary: cognition cannot modify the substrate, active contract, identity, or evidence controls.
6. Tool boundary: tools verify scoped action authority and consequence semantics.
7. Context boundary: all inputs, memory, retrieval, and handoffs carry origin and integrity posture.
8. Evidence boundary: consumers verify producer authority, subject binding, completeness, ordering, and freshness.
9. Implementation boundary: WTK and other systems supply evidence; they do not define architectural truth by implementation alone.

See the trust-boundary diagram.

Governed Action Model

No consequential action is authorized solely because a model requested it.

A governed action binds:

• principal and initiating event;
• workload and artifact identity;
• delegation chain;
• package, contract, and policy digests;
• capability, resource, audience, and purpose;
• input/context integrity posture;
• consequence and retry class;
• authorization decision and human approval when required;
• nonce, validity window, and correlation identifier;
• result, external outcome, and compensation status.

Authority can narrow through delegation but cannot widen. A valid identity or signature does not by itself establish current authority for a specific action.

See the action-authorization sequence.

Context and Information Flow

Context is a governed input surface. Each item should carry enough metadata to reason about:

• origin and principal;
• confidentiality;
• integrity and trust;
• whether content is instruction-eligible;
• permitted transformations and sinks;
• freshness and retention;
• declassification or endorsement authority.

These properties should propagate through retrieval, reasoning, handoffs, tool arguments, outputs, and memory writes. An implementation may use taint labels, capability-safe APIs, isolation, or other mechanisms, but it must demonstrate the claimed flow properties.

Multi-Agent Governance

Role-local compliance is not system compliance. Teams and persistent agent networks require global invariants over:

• communication topology and permitted channels;
• parent-child authority narrowing;
• hop, rate, recursion, concurrency, and financial budgets;
• cycles and propagation;
• evidence-source and judge independence;
• shared memory and information flow;
• composite outcomes and reconstructed capabilities;
• quarantine and network-wide emergency stop.

Consensus is not corroboration unless sources, identities, ownership, and communication paths are sufficiently independent.

Evidence Architecture

Evidence moves through five questions:

1. Authenticity: who produced it and has it changed?
2. Authority: was that producer authorized to make this claim?
3. Applicability: does it bind the correct subject, run, target, and tuple?
4. Completeness: what expected evidence is absent or suppressed?
5. Sufficiency: does the evidence meet the claim's declared threshold?

Hashes establish content relationships, not complete trust. Higher-assurance profiles require signed attestations, trusted time or ordering, anti-replay binding, independent observation, and consumer verification.

See the evidence lifecycle diagram.

Lifecycle and Safe States

The normal lifecycle is:

define -> build -> evaluate -> qualify -> promote -> project -> run -> observe

The architecture also requires explicit non-happy paths:

deny       action is prohibited
ask        authorized judgment is required
degrade    authority or behavior narrows safely
pause      execution stops at a recoverable boundary
quarantine artifact, message, evidence, or network segment is isolated
compensate declared external consequences are reversed or neutralized
rollback   an earlier qualified version is restored
invalidate prior evidence no longer supports its claim
retire     authority and deployment are permanently withdrawn

Safe failure is a valid governed outcome. Fabricated success is not.

Value Model

Dark Factory exists to create value, but value never offsets a safety or authority must-pass failure.

Deployments should measure:

• technical completion;
• goal accomplishment;
• safety and rights preservation;
• quality-adjusted economic value;
• human supervision and correction burden;
• organizational operability;
• effects on downstream and external stakeholders.

Throughput, autonomy, token reduction, or fewer human interactions are not independent measures of success.

Architecture Learning Loop

Implementation evidence may support, narrow, contradict, or falsify an architectural claim. It enters through an explicit research process:

claim -> falsification test -> implementation evidence -> bounded conclusion
      -> retain, revise, narrow, invalidate, or replace architecture guidance

No passing example proves a universal claim. Failed evidence is retained. A material change to model, policy, evaluator, runtime, tool, dependency, or execution form may invalidate earlier confidence.

See the architecture-learning-loop diagram and Challenges to the Dark Factory Hypothesis.

Relationship to WTK

WTK is a reference implementation, experimental system, and evidence source. It may demonstrate, refine, or falsify Dark Factory ideas.

Dark Factory must not:

• require WTK-specific storage, commands, roles, or runtime behavior;
• treat WTK tests as universal conformance;
• convert one target projection into a cross-target guarantee;
• conceal contradictions to preserve architectural consistency.

WTK evidence should enter through explicit claims, scopes, executor tuples, limitations, and invalidation conditions. Other implementations should be able to produce and verify equivalent evidence.

Conformance

A conforming implementation must identify:

1. Which architectural claims it makes.
2. Which profile and risk class apply.
3. Which controls are structural, behavioral, advisory, or absent.
4. Which trust roots and external dependencies it assumes.
5. Which evidence supports every claim.
6. Which failures and degraded modes were tested.
7. What remains untested or inconclusive.
8. What changes invalidate the evidence.

Conformance is never inferred from schema validity alone. Schema validity shows that an artifact is interpretable; runtime and outcome evidence show whether the system behaved as claimed.

Current Architectural Gaps

The following remain active architecture work:

• Canonical metamodel and entity relationships.
• Portable research-claim and evidence-attestation schemas.
• Workload identity and delegated-authority protocol.
• Information-flow labels and transformation semantics.
• Judge qualification and tribunal-independence profile.
• Persistent multi-agent network governance.
• Quarantine, recall, and incident lifecycle.
• Governed-value measurement protocol.
• Risk-based conformance profiles.
• Architecture-decision and research-discovery records.

These gaps are research responsibilities, not hidden implementation assumptions.