# MACHINA Architecture Decision Record

Version: `1.0.0-MACHINA-ADR`
Date: `2026-08-21`
Decision ID: `HP-003`
Request ID: `M2M-MACHINA-ADR-01`
Roadmap slice: `S04`
Status: `ACCEPTED / NON-RUNTIME / NON-CANONICAL`
Decision authority: `USER / HUMAN CONTROL PLANE`
Canonical effect: `NONE`
Implementation state: `NOT STARTED`

## 1. Decision

HP-003 selects one inseparable architecture bundle for MACHINA:

| Clause | Selected disposition | Authority effect |
|---|---|---|
| `THIN_NON_EXECUTION_ENVELOPE` | MACHINA is a small, strict, renderer-neutral reference and validation envelope. | It creates no admission, execution, result, or canonical authority and is never a sixth execution role. |
| `COMPOSABLE_PROFILES` | Domain representations live in separately identified and versioned profiles. | A profile constrains representation; it does not acquire the authority of the domain or provider it describes. |
| `EXTERNAL_LOSS_DECLARING_DUPLEX_BRIDGE` | The ROTA A duplex crosswalk is an external companion to the envelope and profiles. | A bridge translates representations only; it does not infer authority, topology, admission, execution, or provider closure. |
| `SOURCE_ROTAS != INSPECTION_ROTA` | The source ROTAS provider and the post-extraction inspection ROTA are distinct artifacts. | Inspection cannot satisfy or replace the pre-OPERA ROTAS provider bucket. |
| `FIVE_DISTINCT_EXECUTION_OWNERS` | The owners remain `TENET`, `ROTAS`, `AREPO`, `OPERA`, and `SATOR`. | MACHINA owns none of their execution authority, and no local filename proves five-provider closure. |
| `SIGMA_CONTROL_DOSSIER` | The current Sigma artifact remains a control dossier/PENTAGRAMA. | It is neither an executable kernel nor proof of a conforming five-provider assembly. |

The clauses are compositional, not alternatives. The thin envelope supplies a
common reference boundary; profiles preserve domain-specific structure; the
external bridge crosses a specific representation boundary with explicit loss;
the five providers retain their separate authority throughout.

## 2. Context and controlling evidence

The binding source is the maintainer's HP-003 decision recorded on
`2026-08-20`. It approved a thin non-execution envelope with composable
profiles, an external loss-declaring duplex bridge, separate source ROTAS and
inspection ROTA, five owners, and Sigma as a control dossier.

The following material was read as evidence, not imported wholesale:

| Evidence | Authority used here | Relevant finding |
|---|---|---|
| `HP-003_MACHINA_PLACEMENT_AND_SCHEMA_ARCHITECTURE.md` | Human decision record | Supplies the accepted bundle and exact non-authority boundary. |
| `OPERATUM_HP-003-Q-01.md` | Non-canonical evidence dossier | Maps consumers, lossless requirements, owners, and disqualifiers. |
| `OPERATUM_HP-003-T-01.md` | Non-canonical comparative recommendation | Supports the envelope/profile primary shape and bridge companion shape. |
| `MACHINA_STACK_CROSS_IMPLICATION_AUDIT_2026-08-14.md` | Development-only analytical report | Establishes role, ROTA, Sigma, schema, and duplex cross-implications. |
| `MACHINA_CANDIDATE_QUALIFICATION_REPORT_2026-08-16.md` | Non-runtime qualification report | Keeps schema validity, semantic conformance, provider resolution, and execution distinct. |
| `AGLA_MACHINA_CLASS_LAW.md` | Integration candidate/reference alternative | Provides candidate history; it is not selected as canonical law by this decision. |
| `AGLA_ROTA_MACHINA_SCHEMA.json` | Draft candidate schema | Demonstrates the existing broad shape and the risk of generic connection collapse. |
| `ROTA MACHINA EX ROTA.md` | Inspection-ROTA candidate | Identifies the present post-extraction display/traversal surface. |

The two 2026-08 development reports and the aligned class-law candidate were
consulted at local recovery commit
`dbcf87a92986497d0ef2c69a1ee1eca8cd4ed1e8`. That preservation commit is
read-only evidence and is not a merge source. This S04 slice begins from the
verified integration base `57805701d7f78ac1aff00d602a3d5a5419701498`.

## 3. Envelope boundary

The envelope may carry stable identity, kind, version, provenance, native
schema/profile references, lifecycle summaries, validation references,
unresolved-item references, and explicit assembly references. It must remain
small enough that domain models are not duplicated inside it.

The envelope must not:

- execute OPERA, admit through AREPO, mediate as SATOR, or instantiate ROTAS;
- claim canonical status from schema validity or file placement;
- infer an owner, provider, topology, relation, or lifecycle state from a
  filename, visual position, DOM order, generic edge, or naming resemblance;
- embed renderer-specific geometry as universal doctrine;
- treat an execution assembly reference as proof that its providers resolve;
  or
- collapse extraction corpus, representation validity, provider closure,
  admission, execution, and output into one status.

At minimum, later implementation must expose distinct status surfaces for
schema/profile validity, semantic validation, provider resolution, AREPO
admission, OPERA execution, and SATOR output. A PASS in one surface cannot be
promoted into another by implication.

## 4. Composable-profile boundary

Every profile requires its own stable profile ID, version, native schema
reference, compatibility declaration, owner reference, validation entrypoint,
and lifecycle state. Profiles extend the envelope without transferring the
source domain's authority to MACHINA.

The first profile family may model ROTA A duplex, but that profile cannot be
generalized into a transversal common profile core merely because it is the
first implementation. Common fields may be promoted only after multiple real
profiles demonstrate a stable, non-collapsing interface through a separate
review gate.

Renderer and interaction bindings belong in profiles or adapters. They must
remain referential and renderer-neutral at the envelope boundary.

## 5. Duplex bridge and declared loss

The ROTA A duplex has typed loci, cycles, axes, directed carriers, pair keys,
and carrier-first contextual state. A generic `connections[]` record cannot
replace these identities without an explicit, reviewable loss declaration.

The external bridge therefore requires, at minimum:

- a stable bridge ID and version;
- source and target schema/profile IDs and versions;
- mapping direction and compatibility range;
- typed field/identity mappings;
- provenance and source-artifact references;
- for every non-lossless projection, a loss code, affected source paths,
  severity, reversibility, justification, and unresolved consequences;
- an explicit round-trip claim of `LOSSLESS`, `LOSS_DECLARED`, or
  `UNSUPPORTED`; and
- validation evidence for any direction claimed to be lossless.

The native duplex representation remains authoritative for its own structure.
A generic MACHINA projection is an inspection/interchange view, not a new
source of duplex topology or execution truth.

## 6. Source ROTAS and inspection ROTA non-collapse

The source ROTAS provider and the inspection ROTA require separate:

- IDs and namespaces;
- artifact kinds and owners;
- lifecycle and canonicality states;
- manifest fields and provider references;
- provenance chains and source/result timestamps; and
- validation and handoff records.

Their lineage is directional and explicit:

`source ROTAS provider -> admitted OPERA input -> extraction/result -> inspection ROTA`

The inspection ROTA may visualize, traverse, compare, or audit an extracted
machine. Its post-extraction position means it cannot retroactively supply the
source ROTAS provider for that execution. Any later recursive pass is a new
pass with new IDs, owner resolution, AREPO admission, and execution records.

## 7. Five-owner and Sigma invariants

The execution-role topology remains exactly:

`TENET -> ROTAS -> AREPO -> OPERA -> SATOR`

MACHINA is a representation capability outside that order. A conforming
execution assembly must resolve its effective five providers through the
applicable registry and admission controls; similarly named local artifacts
are insufficient.

The current Sigma file is classified as a non-runtime control
dossier/PENTAGRAMA. It may preserve review, comparison, and control-plane
evidence. It must not be called a kernel, executable assembly, or closure proof.
A future pointer or full-fidelity Sigma kernel would require a separate gate,
exact five-provider resolution, compatibility evidence, and its own lifecycle.

## 8. Rejected and deferred alternatives

| Alternative | Disposition | Reason and authority effect |
|---|---|---|
| Monolithic schema | `REJECTED_AS_PRIMARY` | It centralizes domain semantics, increases coupling and drift, and makes authority collapse harder to detect. |
| Generic `connections[]` flattening | `REJECTED` | It cannot silently identify loci, cycles, axes, directed carriers, pair keys, or carrier-keyed state. |
| Manifest-only representation | `REJECTED_AS_PRIMARY` | A manifest supports discovery and assembly references but does not provide the common validation/query envelope or provider closure. |
| Distributed five-role storage | `RETAINED_AS_OWNERSHIP_LAW / REJECTED_AS_PRIMARY_STORAGE_SHAPE` | Distributed ownership remains mandatory; fully distributed primary representation would fragment queries, versioning, and validation. |
| Transversal common profile core | `DEFERRED` | It requires evidence from multiple implemented profiles and a separate review; the first profile cannot define it unilaterally. |
| Continued candidate suite | `RETAINED_AS_REVERSIBLE_FALLBACK` | It preserves evidence but does not close HP-003 or supply the selected architecture. |
| MACHINA root-class promotion | `NOT_SELECTED / SEPARATE_HUMAN_GATE_REQUIRED` | Registration or canonical-law mutation cannot be inferred from this ADR. |

`AGLA_MACHINA_CLASS_LAW.md` is retained as a candidate/reference alternative.
The version present on the integration base and the later aligned candidate in
the recovery evidence do not become canonical root law through this ADR. Any
registration, replacement, canonical-law mutation, provider promotion, or
runtime authority requires a separate human gate and an independently scoped
slice.

## 9. S06 implementation handoff

`M2M-MACHINA-PROFILE-01` becomes eligible after this ADR passes, but execution
does not start automatically. S06 must remain a separate branch and mutation
family. Its required outputs are:

1. a thin envelope schema and contract;
2. a composable profile schema and versioned profile registry;
3. an external ROTA A duplex bridge with machine-readable loss declarations;
4. separate source-ROTAS and inspection-ROTA IDs, namespaces, owners,
   lifecycle fields, manifest fields, and lineage;
5. positive fixtures, negative non-collapse fixtures, round-trip fixtures,
   validators, and reproducible validation commands;
6. separately represented schema/profile validity, semantic validity,
   provider-resolution, admission, execution, and output states; and
7. explicit classification of the current Sigma artifact as a control
   dossier/PENTAGRAMA.

S06 must stop before promotion if it would modify a canonical root law, create
a sixth execution owner, use an inspection artifact as the source provider,
claim an undeclared lossy mapping as lossless, or treat schema validation as
provider or execution closure.

## 10. Consequences and review gates

Positive consequences are lower coupling, renderer neutrality, explicit
provenance, profile-level evolution, and inspectable loss at cross-system
boundaries. Costs are more IDs, registries, adapters, compatibility tests, and
version coordination. Those costs are accepted because they make authority
and information loss observable.

This ADR closes only the architecture decision condition of HP-003. It does
not implement the architecture, canonize MACHINA, release a runtime, resolve
providers, rebuild deployment, or supersede the canonical five-role order.

The decision may be superseded only by a later versioned ADR with explicit
human authority, migration effects, affected profiles/bridges, and treatment
of already published evidence.