ArchitectureCore

The Five Invariants

Post-E.3b, the invariants are documented here as a Core-first enforcement story: Python Core is the normative locus, while app routes and current persistence controls provide defense in depth.

Authoritative Definitions

The BIS 2026 reference-model invariant names and the current Protools runtime projection are deliberately separated. The paper names live in the science alignment page; the matrix below describes what the Core runtime enforces today. Formal citation anchors live inservices/aijim-core/src/aijim_core/spec/and the scope statement inservices/aijim-core/CORE_SCOPE.md. This page is the human-facing enforcement index, not the sole authority that papers should cite.

Paper-to-runtime mapping

The chapter-level I1-I5 terms and the Protools runtime terms are mapped atScience / Paper to Protools Alignment. Use that page when writing papers, research summaries, or protocol claims that need to distinguish the reference model from the shipped runtime.

Current Enforcement Story

The important architecture change is not that the invariants became less strict, but that their ownership is now explicit. Core defines the contracts, rejects invalid writes, and emits stable failure reasons. The Next.js BFF, session/auth forwarding, and existing database or RPC hardening on transitional routes remain useful, but they are defense-in-depth rather than alternative sources of truth. ECAM-X, AEI-Delta, and TCA are not additional invariants; they are scientific evaluation axes that operate under the run and artifact contracts.

Story Artifact Truth Model

Sprint α introduced an explicit truth model for story-facing bodies. The important design move is that AIJIM now separates three questions instead of collapsing them into one label: what the body is, how it was produced, and what a current run is doing.

Artifact kind

Core distinguishes story, outline, and artifact. The app projects those values into the visible badge but does not invent them.

Provenance status

Core persists whether a body is pipeline.complete,pipeline.pending_validation,user.generated, or absent. Missing provenance is not guessed from document shape.

Run-stage status

UI pipeline strips project ephemeral states likerunning or failed. Those are run facts, not persisted artifact identity.

No heuristic provenance

A readable body is not automatically a validated story. If provenance is absent, AIJIM surfaces that body as an Unverified artifact rather than guessing from headings, editor markup, or historical shape. This is the architecture-level expression of the no-black-box rule.

I1–I5 Matrix

Invariant	Core Definition	Normative Enforcement Locus	Defense in Depth	Representative Error Codes
I1 Evidence-first integrity	Core treats evidence and story inputs as the admissibility boundary for downstream work.	`services/aijim-core/src/aijim_core/application/services/story_render_run_service.py`, `story_synthesis_run_service.py`, and related services reject missing or undecided claim inputs before projection or synthesis runs proceed.	Next.js proxies forward actor/session context; transitional LINA-bound audit routes still keep DB/RPC hardening, but those checks are secondary to Core writer ownership.	`selected_claim_revision_ids_required`, `claim_not_decided:{revision_id}`, `snapshot_not_found`
I2 Audit trail and artifact completeness	Runs are only valid when their canonical artifact contract is satisfied.	`services/aijim-core/src/aijim_core/spec/run_contracts.py` defines the expected artifacts per run kind, and Core run services fail closed when persisted artifacts do not match that contract.	Artifact validation is enforced in Core and surfaced through BFF proxies; downstream consumers read persisted manifests instead of trusting client-declared output shape.	`expected_contract_missing_manifest`, `expected_contract_story_render_mismatch`, `run_failed:artifact_validation_failed`
I3 Claim-evidence binding	Narrative and synthesis outputs must stay bound to selected claims and evidence within the declared input pack.	`services/aijim-core/src/aijim_core/infrastructure/policy/rules.py` evaluates binding, no-new-claims, and audit-grade evidence-reference rules for projection outputs.	Core policy reports are normative; app-level read models and UI validation help operators understand violations but do not redefine them.	`story_render_policy_violation:RULE_PARAGRAPH_HAS_CLAIM_BINDING`, `story_render_policy_violation:RULE_NO_EVIDENCE_OUTSIDE_INPUT_PACK`, `story_render_policy_violation:RULE_EVIDENCE_REFS_AUDIT_GRADE`
I4 Human oversight and governance gating	Consequential transitions require explicit policy or review-gate approval rather than silent automation.	Core review-gates, HITL summaries, and policy engine decisions are the normative locus for oversight-bearing actions; this is surfaced through `/api/core/stories/[storyId]/review-gates` and related routes.	The app route layer forwards auth and actor context, while current transitional LINA audit routes remain frozen to security, correctness, and migration shims only.	`policy_denied`, `hitl_summary_missing_or_unbound`, `Unauthorized (missing Supabase session)`
I5 Deterministic replay and fail-closed reproducibility	Stable contracts, explicit run kinds, and fail-closed gates prevent silent divergence in repeat execution paths.	`services/aijim-core/src/aijim_core/spec/run_contracts.py`, `services/aijim-core/src/aijim_core/spec/provider_switch_gate.py`, and run-service snapshot checks provide the current reproducibility backbone.	Core owns the deterministic contract; the BFF and storage layers preserve request identity, auth forwarding, and transition-state hardening without becoming co-equal truth owners.	`invalid_run_kind`, `stale_snapshot_revision`, `provider_switch_gate:fail_closed_violation_detected`

Why the Error Codes Matter

These examples are intentionally current, repo-backed failure surfaces. They show where Core fails closed today, which is more useful for architecture readers than abstract invariant prose alone.