@llm-dev-ops/agentics-cli 1.4.4 → 1.4.7

package/dist/contracts/adr-005-system-coherence-drift-self-governance.js

@@ -0,0 +1,1371 @@
+/**
+ * ADR-005: System Coherence, Drift Detection, and Self-Governance
+ *
+ * STATUS: Accepted
+ * DATE: 2026-01-28
+ * AUTHORS: Platform Engineering
+ * SUPERSEDES: None
+ * DEPENDS ON: ADR-003 (governance architecture), ADR-004 (enterprise integration & memory)
+ * REFERENCED BY: Future implementation ADRs for drift detection, coherence monitoring
+ *
+ * ============================================================================
+ * POSITIONING STATEMENT
+ * ============================================================================
+ *
+ * Agentics does not self-correct decisions — it preserves coherence so
+ * humans can govern change safely.
+ *
+ * As simulations accumulate, integrations evolve, ERP proposals multiply,
+ * and memory grows, the Agentics platform must remain structurally
+ * coherent. Coherence is not a feature to be built — it is an
+ * architectural property that emerges from governed processes and is
+ * eroded by ungoverned ones.
+ *
+ * This ADR defines the conceptual architecture for how the platform:
+ *
+ *   - Detects incoherence and drift across simulations, integrations,
+ *     ERP Surface, and memory
+ *
+ *   - Preserves long-term structural consistency without relying on
+ *     autonomous correction
+ *
+ *   - Supports governed self-management — the ability of the system
+ *     to observe its own state and surface findings to humans who
+ *     make the decisions
+ *
+ * This ADR introduces no new commands, schemas, middleware, tables,
+ * APIs, algorithms, or implementation details. It is a conceptual
+ * framing document that establishes the domains, invariants, and
+ * responsibility boundaries for coherence and drift within the
+ * Agentics platform.
+ *
+ * ============================================================================
+ * CONTEXT
+ * ============================================================================
+ *
+ * The Agentics platform now has:
+ *
+ *   - Governed CLI semantics and synthesis rules (ADR-001) that define
+ *     what every command accepts and when LLM synthesis may occur.
+ *
+ *   - Executable governance via schema, middleware, and CI (ADR-002)
+ *     that mechanically enforces ADR-001's rules at runtime.
+ *
+ *   - A DDD framing for the CLI control plane (ADR-003) that defines
+ *     five bounded contexts, seven invariants, and the governance
+ *     hierarchy that all implementations must respect.
+ *
+ *   - A defined enterprise integration and memory architecture
+ *     (ADR-004) centered on Ruvector, Integrations, and ERP Surface,
+ *     with seven additional invariants governing traceability,
+ *     simulation derivation, and memory authority.
+ *
+ * What is still missing is an explicit architectural model explaining:
+ *
+ *   - How the system detects drift over time. As simulations are
+ *     re-run, as integration definitions evolve, and as ERP Surface
+ *     accumulates proposals, the platform must be able to observe
+ *     whether its state remains internally consistent.
+ *
+ *   - How coherence is preserved as the platform grows. A platform
+ *     with 10 simulations and 5 integrations is easy to reason about.
+ *     A platform with 10,000 simulations, 75 integrations, and
+ *     thousands of ERP proposals is not. Coherence must be
+ *     architectural, not accidental.
+ *
+ *   - How the platform "manages itself" structurally. Self-management
+ *     does not mean autonomous correction. It means the platform can
+ *     observe, compare, and surface — but never unilaterally act.
+ *
+ * Without this model:
+ *
+ *   - Drift accumulates silently. Integration definitions change but
+ *     existing simulations that referenced earlier versions are not
+ *     flagged. ERP proposals derived from outdated simulations remain
+ *     without any indication of staleness.
+ *
+ *   - Contributors build autonomous correction. Without a clear
+ *     statement that the platform does not self-correct, future
+ *     contributors will build "auto-fix" and "auto-heal" features
+ *     that violate the governance model.
+ *
+ *   - Long-term consistency becomes a manual burden. Without
+ *     architectural support for coherence observation, operators
+ *     must manually audit every artifact to determine if the
+ *     platform's state is internally consistent.
+ *
+ *   - The distinction between observation and action blurs. Without
+ *     an explicit boundary, detecting a problem and fixing it
+ *     collapse into a single automated step — removing human
+ *     judgment from enterprise decisions.
+ *
+ * This ADR fills that gap.
+ *
+ * ============================================================================
+ * DECISION
+ * ============================================================================
+ *
+ * The system coherence and self-governance architecture is organized
+ * into five conceptual domains. Each domain has clear responsibilities,
+ * boundaries, and invariants. Together, they describe how the platform
+ * maintains structural integrity over time without autonomous action.
+ *
+ * The five domains are:
+ *
+ *   1. System Coherence
+ *   2. Drift Detection
+ *   3. Governed Self-Management
+ *   4. Memory-Anchored Reality
+ *   5. Human Oversight Boundary
+ *
+ * ============================================================================
+ * DOMAIN 1: SYSTEM COHERENCE
+ * ============================================================================
+ *
+ * DEFINITION:
+ *
+ * System coherence is the property that all artifacts, relationships,
+ * and derivation chains within the Agentics platform are internally
+ * consistent with respect to the governance rules and invariants
+ * defined in ADRs 001-004.
+ *
+ * Coherence is not the same as correctness. A simulation may produce
+ * a plan that is factually wrong about enterprise costs. That plan is
+ * still coherent if it was created through the governed pipeline, is
+ * traceable to a simulation, and is persisted in Ruvector with full
+ * lineage. Coherence is a structural property. Correctness is a
+ * judgment that only humans can make.
+ *
+ * WHAT COHERENCE MEANS IN AGENTICS:
+ *
+ *   Coherence means:
+ *
+ *   - Every artifact traces to its origin. A plan traces to a
+ *     simulation. An integration proposal traces to a plan and a
+ *     simulation. An ERP mapping traces to a simulation that produced
+ *     it. If any artifact exists without a traceable origin, the
+ *     platform is incoherent.
+ *
+ *   - Every derivation chain is intact. If Simulation A produced
+ *     Plan B, and Plan B was approved to produce Deployment C, then
+ *     the chain A → B → C must be reconstructable from Ruvector.
+ *     If any link is missing, the platform is incoherent.
+ *
+ *   - Every artifact was created through governance. If an artifact
+ *     exists in Ruvector without having passed through the 5-gate
+ *     pipeline (ADR-002), the platform is incoherent — regardless
+ *     of whether the artifact's content is "correct."
+ *
+ *   - Every reference resolves. If a plan references Simulation X,
+ *     Simulation X must exist in Ruvector. If an integration proposal
+ *     references Integration Y, Integration Y must exist in the
+ *     Integrations repository. Dangling references are incoherence.
+ *
+ * WHY COHERENCE IS ARCHITECTURAL, NOT BEHAVIORAL:
+ *
+ *   Coherence is not a behavior that the system performs. It is a
+ *   property that the system either has or lacks. The system does not
+ *   "do coherence" — it is coherent (or not) based on whether its
+ *   artifacts satisfy the invariants.
+ *
+ *   This distinction matters because:
+ *
+ *   - Behavioral coherence ("the system behaves consistently") is
+ *     impossible to guarantee in a system that involves LLM synthesis.
+ *     The same natural language input may produce different plans on
+ *     different runs. This is not incoherence — it is the nature of
+ *     synthesis.
+ *
+ *   - Structural coherence ("the system's artifacts satisfy their
+ *     invariants") is verifiable. Every artifact either traces to a
+ *     simulation or it does not. Every derivation chain is either
+ *     intact or it is not. These are binary properties that can be
+ *     checked mechanically.
+ *
+ *   The platform guarantees structural coherence. It does not and
+ *   cannot guarantee that synthesis outputs are consistent across
+ *   time. The distinction between "same inputs, same structure" and
+ *   "same inputs, same outputs" is fundamental to how Agentics works.
+ *
+ * DIFFERENCE BETWEEN LOCAL CORRECTNESS AND SYSTEM COHERENCE:
+ *
+ *   Local correctness means a single artifact is valid in isolation.
+ *   A plan has all required fields. A simulation has a valid identifier.
+ *   An integration proposal has a non-empty description. These checks
+ *   are handled by ADR-002's schema validation and contract enforcement.
+ *
+ *   System coherence means the entire platform's state is internally
+ *   consistent. All derivation chains are intact. All references
+ *   resolve. All artifacts trace to governed origins. No orphaned or
+ *   dangling artifacts exist.
+ *
+ *   A platform can have locally correct artifacts and still be
+ *   incoherent. If a plan is valid but its parent simulation was
+ *   deleted, the plan is locally correct but the system is incoherent.
+ *   If an integration proposal references an integration that no
+ *   longer exists, the proposal is locally correct but the system
+ *   is incoherent.
+ *
+ *   Local correctness is necessary but not sufficient for coherence.
+ *
+ * ============================================================================
+ * DOMAIN 2: DRIFT DETECTION
+ * ============================================================================
+ *
+ * DEFINITION:
+ *
+ * Drift is the gradual divergence of the platform's state from its
+ * intended coherent state. Drift is not a failure — it is an
+ * inevitable consequence of a living system where integrations evolve,
+ * simulations accumulate, and the enterprise landscape changes.
+ *
+ * CATEGORIES OF DRIFT:
+ *
+ *   Semantic Drift:
+ *
+ *     The meaning of terms, categories, or classifications changes
+ *     over time without explicit acknowledgment. A simulation created
+ *     when "cloud migration" meant "lift-and-shift to AWS" may still
+ *     exist when the organization has redefined "cloud migration" to
+ *     mean "multi-cloud Kubernetes." The simulation is structurally
+ *     coherent but semantically stale.
+ *
+ *     Semantic drift is the hardest to detect because it requires
+ *     understanding context, not just structure. The platform cannot
+ *     detect semantic drift autonomously — it can only surface
+ *     temporal and contextual information that enables humans to
+ *     recognize it.
+ *
+ *   Structural Drift:
+ *
+ *     The structure of artifacts, schemas, or integration definitions
+ *     changes in ways that invalidate existing artifacts. A new
+ *     required field is added to integration definitions, but existing
+ *     simulations that referenced the old structure are not updated.
+ *     The derivation chain is intact, but the referenced integration
+ *     now has a different shape than what the simulation consumed.
+ *
+ *     Structural drift is detectable by comparing the structure of
+ *     referenced artifacts against the structure that existed when
+ *     the reference was created.
+ *
+ *   Lineage Drift:
+ *
+ *     The derivation chain between artifacts becomes incomplete or
+ *     inconsistent. A simulation is deleted but its child plans and
+ *     proposals remain. An integration is removed from the repository
+ *     but proposals referencing it persist in Ruvector. A plan's
+ *     parent simulation is re-run with different parameters, but the
+ *     plan still references the original simulation version.
+ *
+ *     Lineage drift is detectable by traversing derivation chains
+ *     and verifying that every link resolves to a valid artifact.
+ *
+ *   Integration Drift:
+ *
+ *     The Integrations repository evolves independently of existing
+ *     simulations. New integrations are added. Existing integrations
+ *     are modified. Integration capabilities change. But simulations
+ *     that were created against an earlier version of the integration
+ *     landscape are not flagged as potentially stale.
+ *
+ *     Integration drift is detectable by comparing the integration
+ *     landscape at simulation creation time against the current
+ *     landscape and identifying differences that affect the
+ *     simulation's assumptions.
+ *
+ * WHY DRIFT IS INEVITABLE IN LARGE SYSTEMS:
+ *
+ *   Drift is inevitable because the platform is a living system.
+ *   Integrations evolve as enterprise systems are upgraded. ERP
+ *   processes change as the business transforms. Simulations
+ *   accumulate and their assumptions become outdated. The enterprise
+ *   context that justified a decision six months ago may no longer
+ *   apply.
+ *
+ *   The platform cannot prevent drift because it cannot prevent the
+ *   world from changing. What it can do is make drift observable —
+ *   and that is a fundamentally different design goal than preventing
+ *   it.
+ *
+ * WHY DETECTION MATTERS MORE THAN PREVENTION:
+ *
+ *   Prevention assumes that the system can identify and block all
+ *   sources of drift at the point of occurrence. This is impossible
+ *   in a system where external factors (enterprise system upgrades,
+ *   organizational changes, regulatory updates) are the primary
+ *   sources of drift. The platform does not control these factors.
+ *
+ *   Detection accepts that drift will occur and focuses on making
+ *   it visible. A platform that detects drift enables humans to
+ *   decide: Is this drift acceptable? Does it invalidate prior
+ *   decisions? Should affected simulations be re-run?
+ *
+ *   Detection preserves human agency. Prevention removes it by
+ *   implying that the system knows which changes are acceptable and
+ *   which are not.
+ *
+ * ============================================================================
+ * DOMAIN 3: GOVERNED SELF-MANAGEMENT
+ * ============================================================================
+ *
+ * DEFINITION:
+ *
+ * Governed self-management is the platform's ability to observe,
+ * compare, and surface information about its own state — without
+ * autonomously acting on that information. The platform manages
+ * itself structurally by maintaining the preconditions for human
+ * governance. It does not govern itself.
+ *
+ * WHAT "SELF-MANAGEMENT" MEANS:
+ *
+ *   Self-management means the platform can:
+ *
+ *   - Observe its own coherence state. The platform can determine
+ *     whether its artifacts satisfy the invariants defined in
+ *     ADRs 003-005. It can identify orphaned artifacts, broken
+ *     lineage chains, dangling references, and stale derivations.
+ *
+ *   - Compare artifacts across time. Because Ruvector stores
+ *     simulation context, the platform can compare the inputs and
+ *     outputs of simulations run at different times. It can identify
+ *     cases where the same scenario produces materially different
+ *     results, indicating that underlying assumptions have changed.
+ *
+ *   - Surface findings to operators. The platform can present its
+ *     observations in structured, actionable reports that describe
+ *     what drift exists, where it exists, and what artifacts are
+ *     affected. These reports are informational. They do not
+ *     prescribe corrective action.
+ *
+ * WHAT "SELF-MANAGEMENT" DOES NOT MEAN:
+ *
+ *   Self-management does NOT mean:
+ *
+ *   - Self-correction. The platform does not fix drift. It does not
+ *     re-run simulations, update proposals, reconcile integration
+ *     definitions, or modify ERP mappings based on detected drift.
+ *     Correction requires human judgment about whether the drift
+ *     matters and what the correct response is.
+ *
+ *   - Autonomous decision-making. The platform does not decide which
+ *     simulations are "stale" and should be archived, which proposals
+ *     are "outdated" and should be revoked, or which integrations
+ *     are "drifted" and should be re-evaluated. These are enterprise
+ *     decisions that humans must make.
+ *
+ *   - Proactive remediation. The platform does not take preventive
+ *     action to avoid future drift. It does not re-run simulations
+ *     on a schedule, automatically refresh integration definitions,
+ *     or periodically validate ERP mappings. These would be
+ *     autonomous behaviors that bypass the governed CLI pipeline.
+ *
+ * CLEAR DISTINCTION: SELF-GOVERNANCE vs AUTOMATION vs AUTONOMY:
+ *
+ *   Self-governance (what Agentics does):
+ *     The platform maintains structural properties that enable
+ *     human governance. It preserves lineage, ensures traceability,
+ *     detects drift, and surfaces findings. Every action the platform
+ *     takes to "manage itself" is observable, auditable, and does not
+ *     modify enterprise decisions.
+ *
+ *   Automation (what Agentics may support, under governance):
+ *     Automation executes predefined, deterministic workflows that
+ *     humans have explicitly configured. A scheduled coherence report
+ *     is automation. A notification when lineage breaks is automation.
+ *     Automation operates within governance — it does what humans
+ *     told it to do, when they told it to do it.
+ *
+ *   Autonomy (what Agentics must NEVER do):
+ *     Autonomy means making enterprise decisions without human
+ *     authorization. Re-running a simulation because drift was
+ *     detected is autonomous. Archiving a "stale" proposal without
+ *     human approval is autonomous. Modifying an ERP mapping based
+ *     on detected integration changes is autonomous. Autonomy
+ *     removes human judgment from the decision loop. The Agentics
+ *     platform is explicitly non-autonomous.
+ *
+ * WHY AGENTICS MUST REMAIN EXPLAINABLE AND AUDITABLE:
+ *
+ *   The platform exists in an enterprise context where every decision
+ *   must be attributable to a human (or to a governed process that
+ *   a human authorized). This is not a design preference — it is a
+ *   requirement imposed by:
+ *
+ *   - Compliance frameworks (SOC2, HIPAA, GDPR, ISO 27001) that
+ *     require traceable decision chains with accountable actors.
+ *
+ *   - Enterprise governance policies that prohibit autonomous system
+ *     changes without human approval.
+ *
+ *   - Risk management requirements that demand a clear separation
+ *     between observation ("we detected drift") and action ("a human
+ *     decided to re-simulate").
+ *
+ *   If the platform autonomously corrects drift, the audit trail
+ *   breaks. The question "Who decided to update this proposal?" has
+ *   the answer "The system decided." In an enterprise context, that
+ *   answer is unacceptable.
+ *
+ * ============================================================================
+ * DOMAIN 4: MEMORY-ANCHORED REALITY (RUVECTOR)
+ * ============================================================================
+ *
+ * DEFINITION:
+ *
+ * Memory-anchored reality is the principle that the platform's
+ * understanding of its own state is grounded in persisted memory
+ * (Ruvector), not in transient computation, inferred relationships,
+ * or assumed consistency. What is in Ruvector is real. What is not
+ * in Ruvector does not exist.
+ *
+ * CONCEPTUAL ROLE OF MEMORY IN DETECTING DRIFT:
+ *
+ *   Drift detection requires comparison. To know that something has
+ *   changed, the platform must know what it looked like before. This
+ *   is the fundamental role of memory in drift detection:
+ *
+ *   - When a simulation is created, the integration landscape is
+ *     recorded as part of the simulation's context in Ruvector.
+ *     Later, the platform can compare the recorded landscape against
+ *     the current landscape and identify differences.
+ *
+ *   - When a plan is derived from a simulation, the derivation
+ *     relationship is recorded in Ruvector. Later, the platform can
+ *     traverse derivation chains and verify that every link still
+ *     resolves.
+ *
+ *   - When an ERP proposal is projected onto the enterprise model,
+ *     the proposal's basis (the simulation that produced it, the
+ *     integration definitions it referenced) is recorded. Later,
+ *     the platform can check whether that basis remains valid.
+ *
+ *   Without memory, drift is undetectable. If the platform does not
+ *   remember what integration definitions looked like when a simulation
+ *   was created, it cannot know whether those definitions have changed.
+ *   Memory is not a convenience — it is the substrate for coherence
+ *   observation.
+ *
+ * WHY LINEAGE ENABLES COMPARISON OVER TIME:
+ *
+ *   Lineage is the explicit record of how artifacts relate to each
+ *   other and how they were produced. Lineage enables time-based
+ *   comparison because it answers the question: "What was the world
+ *   like when this artifact was created?"
+ *
+ *   A simulation created on January 15 referenced Integration V2.3 of
+ *   SAP. The current integration version is V3.1. Lineage tells the
+ *   platform that the simulation's context assumed V2.3. The platform
+ *   can then surface: "This simulation was created against SAP V2.3.
+ *   The current version is V3.1. Changes may affect this simulation's
+ *   conclusions."
+ *
+ *   Without lineage, this comparison is impossible. The platform would
+ *   know only the current state of integrations, with no way to
+ *   determine what state existed when any given simulation was created.
+ *
+ * WHY REPLAY AND DIFFING ARE ARCHITECTURAL PRIMITIVES:
+ *
+ *   Replay — the ability to re-execute a simulation's synthesis
+ *   phase with recorded inputs — is not a feature. It is an
+ *   architectural primitive that makes drift observable.
+ *
+ *   When the platform replays a simulation and the output differs
+ *   from the original, the difference is a signal. That signal may
+ *   indicate that the synthesis engine has changed, that integration
+ *   definitions have evolved, or that enterprise context has shifted.
+ *   The platform does not interpret the signal — it presents it to
+ *   humans.
+ *
+ *   Diffing — the ability to compare two versions of an artifact,
+ *   two simulation outputs, or two states of the integration
+ *   landscape — is the mechanism by which replay signals become
+ *   actionable. A diff that says "the cost projection changed by
+ *   40%" is more useful than a signal that says "something changed."
+ *
+ *   Replay and diffing are architectural primitives because they are
+ *   the fundamental operations through which coherence becomes
+ *   observable. They are not features to be added later — they are
+ *   capabilities that the memory architecture must support from the
+ *   beginning.
+ *
+ * ============================================================================
+ * DOMAIN 5: HUMAN OVERSIGHT BOUNDARY
+ * ============================================================================
+ *
+ * DEFINITION:
+ *
+ * The human oversight boundary defines where human judgment is
+ * mandatory in the Agentics platform. It establishes an explicit
+ * line between what the platform may do autonomously (observe,
+ * compare, surface) and what requires human authorization (correct,
+ * approve, execute, archive).
+ *
+ * WHERE HUMANS REMAIN MANDATORY:
+ *
+ *   Enterprise decisions:
+ *     Every decision that affects the enterprise — approving a plan,
+ *     executing a deployment, enabling a policy, rolling back a change
+ *     — requires explicit human authorization through a
+ *     COMMITMENT_GRADE command with --force confirmation. The platform
+ *     presents information. Humans decide.
+ *
+ *   Drift response:
+ *     When the platform detects drift, the response is always a human
+ *     decision. The platform surfaces: "These simulations may be
+ *     affected by changes to Integration X." The human decides: re-run
+ *     the simulations, accept the drift, or investigate further. The
+ *     platform never decides autonomously which response is appropriate.
+ *
+ *   Coherence remediation:
+ *     When the platform identifies incoherence (orphaned artifacts,
+ *     broken lineage, dangling references), remediation is a human
+ *     action. The platform surfaces: "Plan Y references Simulation Z,
+ *     which no longer exists." The human decides: delete the plan,
+ *     re-create the simulation, or accept the orphaned state. The
+ *     platform never cleans up autonomously.
+ *
+ *   Archival and retention:
+ *     Decisions about which simulations to archive, which proposals
+ *     to retire, and which artifacts to retain are enterprise
+ *     governance decisions. The platform may surface recommendations
+ *     ("This simulation is 18 months old and has not been referenced").
+ *     The human decides whether to archive it.
+ *
+ *   Interpretation:
+ *     The platform produces observations, not judgments. "Simulation A
+ *     and Simulation B produce different cost projections for the same
+ *     scenario" is an observation. "Simulation A is outdated" is a
+ *     judgment. The platform makes observations. Humans make judgments.
+ *
+ * WHY EXECUTIVE AND OPERATOR JUDGMENT IS PRESERVED:
+ *
+ *   Enterprise decisions have consequences that extend beyond the
+ *   platform's scope. A deployment affects real systems, real budgets,
+ *   real compliance obligations, and real people. The platform cannot
+ *   understand these consequences because they exist outside its
+ *   memory and governance model.
+ *
+ *   A simulation may show that a migration saves $2M annually. An
+ *   executive may reject it because a regulatory change makes the
+ *   target architecture non-compliant next quarter. The platform
+ *   does not know about the regulatory change. If it autonomously
+ *   acted on the simulation's recommendation, it would make the
+ *   wrong decision.
+ *
+ *   Human judgment is not a limitation of the platform. It is a
+ *   feature. It ensures that enterprise decisions account for context
+ *   that the platform cannot observe.
+ *
+ * HOW THE SYSTEM SUPPORTS HUMANS WITHOUT REPLACING THEM:
+ *
+ *   The platform supports human decision-making by:
+ *
+ *   - Preserving context. Every simulation, plan, proposal, and
+ *     decision is recorded with full context in Ruvector. Humans
+ *     never need to reconstruct "why did we decide this?" — the
+ *     platform remembers.
+ *
+ *   - Surfacing drift. The platform identifies when underlying
+ *     assumptions have changed. Humans do not need to manually
+ *     compare integration versions or check simulation freshness —
+ *     the platform observes and reports.
+ *
+ *   - Enabling comparison. When humans need to evaluate alternatives,
+ *     the platform can replay simulations, diff outputs, and present
+ *     structured comparisons. Humans make the judgment; the platform
+ *     provides the evidence.
+ *
+ *   - Maintaining traceability. When a decision is questioned — by
+ *     auditors, executives, or future contributors — the platform
+ *     provides the complete decision trail. Every artifact traces
+ *     to a simulation, a plan, a human authorization, and a
+ *     governance checkpoint.
+ *
+ *   The platform is an enterprise decision system that amplifies
+ *   human judgment. It is not an AI tool that replaces it.
+ *
+ * ============================================================================
+ * SYSTEM-LEVEL INVARIANTS (NON-NEGOTIABLE)
+ * ============================================================================
+ *
+ * The following are system-level truths that all implementations
+ * must preserve. These invariants extend — and do not replace — the
+ * invariants defined in ADR-003 (Invariants 1-7) and ADR-004
+ * (Invariants 1-7).
+ *
+ * INVARIANT 1: Every enterprise decision must remain traceable
+ *   over time.
+ *
+ *   Traceability is not a point-in-time property. A decision must
+ *   be traceable not only at creation but indefinitely afterward.
+ *   The deletion or modification of upstream artifacts (simulations,
+ *   plans, integration definitions) must not destroy the traceability
+ *   of downstream decisions. If traceability degrades, the platform
+ *   must detect and surface this as a coherence violation.
+ *
+ * INVARIANT 2: No integration or ERP proposal exists without
+ *   historical context.
+ *
+ *   Every proposal must record the context in which it was created:
+ *   which integration definitions were current, what simulation
+ *   parameters were used, what governance version was applied, and
+ *   who authorized the simulation. This historical context is the
+ *   basis for future drift detection. A proposal without historical
+ *   context is undiffable and therefore unmonitorable.
+ *
+ * INVARIANT 3: Drift may be detected but never silently corrected.
+ *
+ *   When the platform detects drift — stale simulations, changed
+ *   integration definitions, broken lineage — it must surface the
+ *   finding and wait for human response. The platform must not
+ *   silently update, reconcile, archive, or discard artifacts
+ *   based on detected drift. Silent correction is indistinguishable
+ *   from data corruption from an audit perspective.
+ *
+ * INVARIANT 4: Memory is authoritative; projections are derived.
+ *
+ *   Ruvector's stored artifacts are the authoritative record of
+ *   what the platform has produced. Any view, dashboard, report,
+ *   or comparison that the platform presents is a projection derived
+ *   from Ruvector's records. If a projection contradicts Ruvector,
+ *   Ruvector is correct and the projection is wrong. Projections
+ *   must never modify memory; they are read-only derivations.
+ *
+ * INVARIANT 5: Self-management never bypasses governance.
+ *
+ *   Any action the platform takes to manage its own state — producing
+ *   coherence reports, detecting drift, comparing simulations,
+ *   traversing lineage — must be a read-only operation against
+ *   Ruvector. Self-management never writes to Ruvector, never
+ *   modifies artifacts, never creates new artifacts, and never
+ *   triggers the governed CLI pipeline without explicit human
+ *   initiation.
+ *
+ * ============================================================================
+ * CONCEPTUAL LIFECYCLE (DESCRIPTIVE ONLY)
+ * ============================================================================
+ *
+ * The following describes, in prose, how the platform accumulates
+ * state over time and how coherence becomes observable. This is a
+ * conceptual description. It is not a specification, a workflow
+ * definition, or an implementation guide.
+ *
+ * ACCUMULATION:
+ *
+ *   Over months and years of operation, the Agentics platform
+ *   accumulates simulations, plans, proposals, and decisions. Each
+ *   simulation captures a snapshot of the enterprise context at the
+ *   time it was created: which integrations existed, what their
+ *   capabilities were, what constraints applied, and what the user
+ *   asked the system to reason about.
+ *
+ *   As new simulations are created, the integration landscape
+ *   evolves. New enterprise systems are added. Existing systems are
+ *   upgraded. Capabilities change. Constraints shift. Each new
+ *   simulation captures the current landscape, but earlier
+ *   simulations retain the landscape as it was.
+ *
+ * COMPARISON:
+ *
+ *   Because Ruvector stores the context of every simulation, the
+ *   platform can compare any two points in time. A simulation from
+ *   January can be compared against a simulation from July — not
+ *   just in terms of their outputs, but in terms of the enterprise
+ *   context that informed them.
+ *
+ *   Comparison reveals divergence. If two simulations of the same
+ *   scenario produce different cost projections, the platform can
+ *   present the differences alongside the contextual changes that
+ *   may explain them. "The January simulation assumed 50 EC2
+ *   instances at $X/month. The July simulation assumed 120 Kubernetes
+ *   pods at $Y/month. The integration landscape changed between
+ *   these runs: AWS integration was updated from V2 to V3."
+ *
+ * DRIFT BECOMES OBSERVABLE:
+ *
+ *   Drift becomes observable when the platform compares the context
+ *   of an existing artifact against the current state of the system.
+ *   The observation takes one of several forms:
+ *
+ *   - An integration definition that a simulation referenced has
+ *     been modified. The simulation's assumptions may no longer hold.
+ *
+ *   - A derivation chain has a broken link. An artifact's parent
+ *     no longer exists, making the artifact an orphan.
+ *
+ *   - A replay of a simulation produces materially different output.
+ *     Something in the synthesis context has changed.
+ *
+ *   - Multiple proposals for the same enterprise process are based
+ *     on different simulation contexts. The proposals may be
+ *     contradictory.
+ *
+ *   Each of these is an observation, not a judgment. The platform
+ *   records the observation and makes it available to operators.
+ *
+ * HUMANS ARE ALERTED OR INFORMED:
+ *
+ *   When drift is detected, the platform surfaces the finding through
+ *   governed channels. The specific mechanism — a report, a
+ *   notification, a dashboard entry, a CLI command output — is an
+ *   implementation concern. The conceptual requirement is that drift
+ *   findings reach a human who can evaluate them.
+ *
+ *   The finding includes:
+ *
+ *   - What was detected (the type of drift)
+ *   - Where it was detected (which artifacts are affected)
+ *   - What changed (the specific difference between the recorded
+ *     context and the current state)
+ *   - When the drift originated (the timestamp of the change)
+ *
+ *   The finding does NOT include:
+ *
+ *   - A recommendation for corrective action
+ *   - A severity judgment
+ *   - An automatic remediation option
+ *   - A comparison to similar drift events
+ *
+ *   The platform presents facts. Humans interpret them.
+ *
+ * CORRECTIONS OCCUR THROUGH GOVERNED WORKFLOWS:
+ *
+ *   When a human decides that drift requires a response, the
+ *   response flows through the governed CLI pipeline. If a
+ *   simulation needs to be re-run, the human issues a simulate
+ *   command. If a plan needs to be revised, the human issues a
+ *   plan command. If a deployment needs to be rolled back, the
+ *   human issues a deploy rollback command with --force confirmation.
+ *
+ *   There is no "fix drift" command. There is no "reconcile" button.
+ *   There is no "auto-heal" workflow. Corrections are composed from
+ *   the existing governed command vocabulary. The governed pipeline
+ *   ensures that every correction is subject to the same governance
+ *   as the original action: identity attribution, synthesis
+ *   classification, gate validation, and Ruvector persistence.
+ *
+ *   This means that corrective actions are indistinguishable from
+ *   original actions in the audit trail. A simulation re-run due
+ *   to drift is just another simulation. A plan revision is just
+ *   another plan. The platform does not distinguish between "first
+ *   time" and "correction" — all actions are governed equally.
+ *
+ * ============================================================================
+ * RELATIONSHIP TO EXISTING ADRS
+ * ============================================================================
+ *
+ * ADR-005 is additive to the governance hierarchy established by
+ * ADRs 001-004. It does not rewrite, replace, or contradict any
+ * prior ADR.
+ *
+ *   ADR-003 → defines the CLI control plane conceptual model
+ *     ↓
+ *   ADR-004 → defines the enterprise integration conceptual model
+ *     ↓
+ *   ADR-005 → defines how coherence and drift are governed over time
+ *     ↓
+ *   ADR-001 → instantiates the models (command registry + types)
+ *     ↓
+ *   ADR-002 → enforces the models (gates + CI + regression tests)
+ *
+ * Specifically:
+ *
+ * - ADR-003's five CLI domains (Control Plane, Command Semantics,
+ *   Synthesis Governance, Execution & State Mutation, Governance
+ *   Source of Truth) remain unchanged. ADR-005's five coherence
+ *   domains are complementary. They describe how ADR-003's domains
+ *   maintain integrity over time.
+ *
+ * - ADR-003's execution phases (Planning → Execution → Commitment →
+ *   Rollback) are the mechanisms through which drift corrections
+ *   occur. ADR-005 does not introduce new lifecycle phases.
+ *
+ * - ADR-004's enterprise domains (Simulation, Memory, Integration,
+ *   ERP Surface, CLI as Orchestrator) are the subjects of ADR-005's
+ *   drift detection. ADR-005 describes how those domains' artifacts
+ *   are monitored for coherence.
+ *
+ * - ADR-004's invariants (particularly Invariant 4: Ruvector as
+ *   memory authority) are the foundation for ADR-005's
+ *   memory-anchored reality principle.
+ *
+ * - ADR-001's command vocabulary is the mechanism through which
+ *   humans respond to detected drift. ADR-005 does not introduce
+ *   new commands.
+ *
+ * - ADR-002's gate pipeline ensures that drift corrections (like
+ *   all actions) pass governance validation. ADR-005 relies on this
+ *   enforcement and does not duplicate it.
+ *
+ * No existing ADR needs to be edited as a result of ADR-005.
+ *
+ * ============================================================================
+ * CONSEQUENCES
+ * ============================================================================
+ *
+ * POSITIVE:
+ *
+ *   - The platform's long-term integrity is explainable. A stakeholder
+ *     can read this ADR and understand how the platform maintains
+ *     coherence without requiring autonomous behavior.
+ *
+ *   - Future contributors understand how drift is handled. The clear
+ *     separation between detection (platform) and correction (human)
+ *     prevents the introduction of autonomous remediation features.
+ *
+ *   - No prior ADR needs revision. ADR-005 is purely additive,
+ *     filling a conceptual gap without contradicting existing
+ *     decisions.
+ *
+ *   - The platform reads as an enterprise decision system, not an AI
+ *     tool. The emphasis on human oversight, auditability, and
+ *     governed workflows positions the platform as infrastructure
+ *     for decision-making rather than a replacement for it.
+ *
+ *   - Self-management is structural, not magical. There is no
+ *     "auto-heal" mystique. The platform observes, compares, and
+ *     surfaces. Humans govern.
+ *
+ *   - The distinction between observation and action is explicit.
+ *     Future contributors cannot accidentally build autonomous
+ *     correction by confusing "detect" with "fix."
+ *
+ * NEGATIVE:
+ *
+ *   - Drift correction requires human effort. The platform does not
+ *     automate responses to drift, which means operators must monitor
+ *     drift reports and take manual action. This is intentional —
+ *     the alternative (autonomous correction) violates the governance
+ *     model.
+ *
+ *   - The conceptual ADR chain (003, 004, 005) is now three documents.
+ *     Contributors must understand the coherence model in addition to
+ *     the CLI control plane and enterprise integration models.
+ *     However, ADR-005 addresses a distinct concern (long-term
+ *     integrity) that is not covered by the other conceptual ADRs.
+ *
+ *   - The invariant that drift is "never silently corrected" may
+ *     frustrate contributors who want to build intelligent
+ *     auto-remediation. This frustration is the point — the invariant
+ *     exists to prevent well-intentioned autonomy from undermining
+ *     governance.
+ *
+ * ============================================================================
+ * EXPLICIT NON-GOALS
+ * ============================================================================
+ *
+ *   1. This ADR does NOT introduce new CLI commands.
+ *      Drift detection and coherence reporting will be exposed
+ *      through existing or future commands defined in ADR-001.
+ *      This ADR defines the conceptual domains, not the commands.
+ *
+ *   2. This ADR does NOT define schemas, tables, or APIs.
+ *      How drift observations are stored, queried, or surfaced is
+ *      an implementation concern for future ADRs.
+ *
+ *   3. This ADR does NOT describe middleware, jobs, or code.
+ *      There are no background processes, cron jobs, or event
+ *      handlers specified here. Implementation mechanisms belong
+ *      in future implementation ADRs.
+ *
+ *   4. This ADR does NOT specify algorithms or heuristics.
+ *      How drift is detected — what thresholds trigger observations,
+ *      what comparison methods are used, how staleness is calculated
+ *      — is an implementation concern. This ADR defines what drift
+ *      IS and what the platform's responsibilities are, not how
+ *      drift is computed.
+ *
+ *   5. This ADR does NOT propose automation or autonomous correction.
+ *      The platform observes and surfaces. It does not fix, reconcile,
+ *      archive, or remediate. Any future automation must be explicitly
+ *      human-configured and must not violate Invariant 3.
+ *
+ *   6. This ADR does NOT re-state or modify prior ADR decisions.
+ *      It extends the conceptual architecture into the coherence
+ *      and drift space, which was not covered by ADRs 001-004.
+ *
+ * ============================================================================
+ * ANTI-PATTERNS (WHAT FUTURE CONTRIBUTORS MUST NOT DO)
+ * ============================================================================
+ *
+ * ANTI-PATTERN 1: SILENT AUTO-CORRECTION
+ *
+ *   What it looks like:
+ *     A background job detects that a simulation's integration
+ *     references are outdated. It automatically re-runs the
+ *     simulation with updated integration definitions and replaces
+ *     the original results in Ruvector.
+ *
+ *   Why it's wrong:
+ *     Silent correction destroys the audit trail. The original
+ *     simulation's results — which may have been reviewed, approved,
+ *     and used to justify enterprise decisions — are overwritten.
+ *     An auditor asking "What did the original simulation conclude?"
+ *     gets the corrected answer, not the original. This violates
+ *     Invariant 3 and is indistinguishable from data tampering.
+ *
+ *   What to do instead:
+ *     Surface the drift. Present: "Simulation X referenced
+ *     Integration V2.3. The current version is V3.1." Let the
+ *     human decide whether to re-run the simulation. If they do,
+ *     it creates a NEW simulation with its own lineage — the
+ *     original is preserved.
+ *
+ * ANTI-PATTERN 2: AUTONOMOUS ARCHIVAL
+ *
+ *   What it looks like:
+ *     A system policy automatically archives simulations older than
+ *     90 days. A "staleness" algorithm marks proposals as "outdated"
+ *     and removes them from active views.
+ *
+ *   Why it's wrong:
+ *     Retention is an enterprise governance decision, not a system
+ *     behavior. A simulation from two years ago may still be the
+ *     basis for an active deployment. An "old" proposal may be
+ *     under regulatory review. Autonomous archival removes artifacts
+ *     that humans may need, based on the system's assumption about
+ *     what is "stale." This violates Invariant 5.
+ *
+ *   What to do instead:
+ *     Surface retention observations: "These 47 simulations are
+ *     older than 12 months and have no downstream references."
+ *     Let the operator decide whether to archive them. Archival
+ *     is a governed action, not an automatic one.
+ *
+ * ANTI-PATTERN 3: DRIFT SEVERITY SCORING
+ *
+ *   What it looks like:
+ *     The platform assigns "severity scores" to detected drift.
+ *     "Critical: Integration SAP changed from V2 to V3. 12
+ *     simulations affected." "Low: Integration Slack updated
+ *     description text. 2 simulations reference it."
+ *
+ *   Why it's wrong:
+ *     Severity is a judgment, not a measurement. A "minor" text
+ *     change in a Slack integration might be irrelevant to most
+ *     simulations but critical to one that depends on specific
+ *     notification behavior. A "major" version change in SAP might
+ *     be backward-compatible and affect nothing. The platform does
+ *     not understand enterprise context deeply enough to assign
+ *     severity accurately. False severity scores create false
+ *     confidence or false urgency.
+ *
+ *   What to do instead:
+ *     Present the facts without judgment: "Integration SAP changed
+ *     from V2.3 to V3.1. 12 simulations referenced V2.3." The
+ *     human determines whether this matters.
+ *
+ * ANTI-PATTERN 4: PREDICTIVE DRIFT PREVENTION
+ *
+ *   What it looks like:
+ *     The platform analyzes integration change patterns and
+ *     "pre-emptively" re-runs simulations that are "likely" to be
+ *     affected by upcoming changes.
+ *
+ *   Why it's wrong:
+ *     Prediction requires modeling the future behavior of enterprise
+ *     systems, organizational decisions, and market conditions. The
+ *     platform does not have access to these signals. Predictive
+ *     prevention creates false confidence ("the system already
+ *     accounted for this change") and wastes resources on
+ *     simulations that may never be needed. Worse, it conflates
+ *     prediction with governance — the platform is making decisions
+ *     about what to simulate without human authorization.
+ *
+ *   What to do instead:
+ *     When changes occur, surface them. Let humans decide which
+ *     simulations to re-run based on their understanding of the
+ *     enterprise context.
+ *
+ * ANTI-PATTERN 5: OVER-AUTOMATION OF COHERENCE CHECKS
+ *
+ *   What it looks like:
+ *     Every artifact write triggers a full coherence check across
+ *     the entire platform. Every integration change triggers
+ *     notifications to all simulation owners. The system produces
+ *     so many coherence observations that operators learn to
+ *     ignore them.
+ *
+ *   Why it's wrong:
+ *     Over-automation creates noise. When every change generates
+ *     observations, the signal-to-noise ratio collapses. Operators
+ *     stop reading coherence reports. Critical drift observations
+ *     are lost in a flood of irrelevant notifications. The system
+ *     that was designed to make drift visible inadvertently makes
+ *     it invisible through volume.
+ *
+ *   What to do instead:
+ *     Coherence checks should be invoked through governed workflows
+ *     — not triggered automatically on every state change. Humans
+ *     decide when to check coherence and at what scope.
+ *
+ * ============================================================================
+ * SUCCESS CRITERIA
+ * ============================================================================
+ *
+ * This ADR is successful if:
+ *
+ *   1. The system's long-term integrity is explainable. A new
+ *      contributor, a stakeholder, or an auditor can read this
+ *      document and understand how the platform maintains
+ *      coherence over time — without reading implementation code.
+ *
+ *   2. Future contributors understand how drift is handled.
+ *      The detect-surface-wait pattern is clear. No contributor
+ *      builds autonomous correction without explicitly violating
+ *      a stated invariant.
+ *
+ *   3. No prior ADR needs revision. ADR-005 is additive. ADRs
+ *      001, 002, 003, and 004 remain unchanged and uncontradicted.
+ *
+ *   4. The platform reads as an enterprise decision system, not an
+ *      AI tool. The emphasis on human oversight, governed workflows,
+ *      and non-autonomous behavior positions the platform as
+ *      infrastructure for enterprise governance.
+ *
+ *   5. Self-management is structural, not magical. The document
+ *      makes clear that "self-managing" means observing and surfacing,
+ *      not deciding and acting. There is no mystique about what the
+ *      platform does on its own.
+ *
+ * ============================================================================
+ * ALTERNATIVES CONSIDERED
+ * ============================================================================
+ *
+ * A. Embed coherence concepts into ADR-004:
+ *    Rejected — ADR-004 defines the enterprise integration and
+ *    memory domains. Coherence and drift are cross-cutting concerns
+ *    that apply to all domains (CLI, integration, ERP Surface, memory).
+ *    Embedding them in ADR-004 would make coherence appear to be
+ *    an integration concern rather than a system-wide property.
+ *
+ * B. Define specific drift detection algorithms:
+ *    Rejected — algorithms are implementation concerns. This ADR
+ *    defines what drift IS, what the platform's responsibilities
+ *    are, and what boundaries apply. How drift is computed belongs
+ *    in a future implementation ADR.
+ *
+ * C. Allow limited autonomous correction for "safe" cases:
+ *    Rejected — "safe" autonomous correction is a category error.
+ *    Safety is a judgment that requires enterprise context. A
+ *    correction that is "safe" from a structural perspective may be
+ *    unsafe from a regulatory, financial, or organizational
+ *    perspective. The platform cannot evaluate these dimensions.
+ *    Therefore, no correction is autonomous.
+ *
+ * D. Combine coherence and governance into a single domain:
+ *    Rejected — governance (ADR-003) defines how decisions are
+ *    made and enforced. Coherence (ADR-005) defines how decisions
+ *    remain structurally consistent over time. These are related
+ *    but distinct concerns. Combining them would blur the boundary
+ *    between "how we decide" and "how we verify that our decisions
+ *    remain valid."
+ *
+ * E. Introduce a "drift" command category:
+ *    Rejected — this ADR does not introduce commands. If drift
+ *    detection commands are needed, they will be defined in ADR-001
+ *    (command registry) and governed by ADR-002 (enforcement), per
+ *    the established ADR hierarchy.
+ */
+// ============================================================================
+// ADR-005 Metadata
+// ============================================================================
+// This ADR is purely conceptual. It exports only its own metadata
+// for identification and cross-referencing by other ADRs.
+// It contains no schemas, no middleware, no algorithms, no runtime code.
+// ============================================================================
+export const ADR_005_ID = 'ADR-005';
+export const ADR_005_TITLE = 'System Coherence, Drift Detection, and Self-Governance';
+export const ADR_005_STATUS = 'Accepted';
+export const ADR_005_DATE = '2026-01-28';
+// ============================================================================
+// ADR-005 Implementation: Constants
+// ============================================================================
+/**
+ * The five system-level invariants from ADR-005.
+ */
+export const COHERENCE_INVARIANTS = [
+    {
+        number: 1,
+        id: 'INV-005-01',
+        description: 'Every enterprise decision must remain traceable over time',
+        domain: 'MEMORY_ANCHORED_REALITY',
+    },
+    {
+        number: 2,
+        id: 'INV-005-02',
+        description: 'No integration or ERP proposal exists without historical context',
+        domain: 'SYSTEM_COHERENCE',
+    },
+    {
+        number: 3,
+        id: 'INV-005-03',
+        description: 'Drift may be detected but never silently corrected',
+        domain: 'DRIFT_DETECTION',
+    },
+    {
+        number: 4,
+        id: 'INV-005-04',
+        description: 'Memory is authoritative; projections are derived',
+        domain: 'MEMORY_ANCHORED_REALITY',
+    },
+    {
+        number: 5,
+        id: 'INV-005-05',
+        description: 'Self-management never bypasses governance',
+        domain: 'GOVERNED_SELF_MANAGEMENT',
+    },
+];
+/**
+ * Coherence domain definitions.
+ */
+export const COHERENCE_DOMAINS = {
+    SYSTEM_COHERENCE: {
+        name: 'System Coherence',
+        description: 'Structural property: lineage intact, references resolve, governed origins',
+        verifiable: true,
+    },
+    DRIFT_DETECTION: {
+        name: 'Drift Detection',
+        description: 'Temporal divergence observation across 4 categories',
+        verifiable: true,
+    },
+    GOVERNED_SELF_MANAGEMENT: {
+        name: 'Governed Self-Management',
+        description: 'Observe/compare/surface — NEVER correct/decide/remediate',
+        verifiable: true,
+    },
+    MEMORY_ANCHORED_REALITY: {
+        name: 'Memory-Anchored Reality',
+        description: 'Ruvector as authoritative substrate; replay and diffing as primitives',
+        verifiable: true,
+    },
+    HUMAN_OVERSIGHT_BOUNDARY: {
+        name: 'Human Oversight Boundary',
+        description: 'Human mandatory for decisions, drift response, remediation, archival, interpretation',
+        verifiable: false,
+    },
+};
+/**
+ * Drift category definitions.
+ */
+export const DRIFT_CATEGORIES = {
+    SEMANTIC_DRIFT: {
+        name: 'Semantic Drift',
+        description: 'Meaning changes without acknowledgment',
+        detectable_automatically: false,
+    },
+    STRUCTURAL_DRIFT: {
+        name: 'Structural Drift',
+        description: 'Schema or definition shape changes',
+        detectable_automatically: true,
+    },
+    LINEAGE_DRIFT: {
+        name: 'Lineage Drift',
+        description: 'Broken or incomplete derivation chains',
+        detectable_automatically: true,
+    },
+    INTEGRATION_DRIFT: {
+        name: 'Integration Drift',
+        description: 'Integration landscape evolution',
+        detectable_automatically: true,
+    },
+};
+/**
+ * Self-management capabilities (all read-only, all allowed).
+ */
+export const SELF_MANAGEMENT_CAPABILITIES = {
+    OBSERVE_COHERENCE: {
+        name: 'Observe Coherence',
+        boundary: 'OBSERVATION',
+        read_only: true,
+        requires_human: false,
+    },
+    COMPARE_ARTIFACTS: {
+        name: 'Compare Artifacts',
+        boundary: 'OBSERVATION',
+        read_only: true,
+        requires_human: false,
+    },
+    SURFACE_FINDINGS: {
+        name: 'Surface Findings',
+        boundary: 'OBSERVATION',
+        read_only: true,
+        requires_human: false,
+    },
+    TRAVERSE_LINEAGE: {
+        name: 'Traverse Lineage',
+        boundary: 'OBSERVATION',
+        read_only: true,
+        requires_human: false,
+    },
+    DETECT_DRIFT: {
+        name: 'Detect Drift',
+        boundary: 'OBSERVATION',
+        read_only: true,
+        requires_human: false,
+    },
+    REPLAY_SIMULATION: {
+        name: 'Replay Simulation',
+        boundary: 'OBSERVATION',
+        read_only: true,
+        requires_human: false,
+    },
+};
+/**
+ * Prohibited autonomous actions (all forbidden, each references an invariant).
+ */
+export const PROHIBITED_AUTONOMY = {
+    AUTO_CORRECT_DRIFT: {
+        name: 'Auto-Correct Drift',
+        boundary: 'AUTONOMOUS_ACTION',
+        violates_invariant: 3,
+        reason: 'Drift may be detected but never silently corrected',
+    },
+    AUTO_ARCHIVE: {
+        name: 'Auto-Archive',
+        boundary: 'AUTONOMOUS_ACTION',
+        violates_invariant: 5,
+        reason: 'Self-management never bypasses governance',
+    },
+    AUTO_REMEDIATE: {
+        name: 'Auto-Remediate',
+        boundary: 'AUTONOMOUS_ACTION',
+        violates_invariant: 3,
+        reason: 'Remediation requires human decision',
+    },
+    AUTO_RERUN: {
+        name: 'Auto-Rerun',
+        boundary: 'AUTONOMOUS_ACTION',
+        violates_invariant: 5,
+        reason: 'Simulation execution must be human-initiated',
+    },
+    AUTO_RECONCILE: {
+        name: 'Auto-Reconcile',
+        boundary: 'AUTONOMOUS_ACTION',
+        violates_invariant: 4,
+        reason: 'Memory is authoritative; cannot be auto-modified',
+    },
+    AUTO_SEVERITY_SCORE: {
+        name: 'Auto-Severity Score',
+        boundary: 'AUTONOMOUS_ACTION',
+        violates_invariant: 3,
+        reason: 'Severity is a judgment that requires enterprise context',
+    },
+};
+/**
+ * Action verb patterns for boundary classification.
+ */
+export const ACTION_BOUNDARIES = {
+    read_operations: ['query', 'list', 'inspect', 'compare', 'traverse', 'observe', 'detect', 'replay', 'surface', 'check'],
+    write_operations: ['correct', 'fix', 'remediate', 'archive', 'reconcile', 'update', 'delete', 'modify', 'overwrite'],
+    judgment_operations: ['score', 'prioritize', 'recommend', 'decide', 'classify-severity', 'rank'],
+};
+// ============================================================================
+// ADR-005 Implementation: Validation Functions
+// ============================================================================
+/**
+ * Classify an action as observation, autonomous, or governed.
+ *
+ * Uses verb pattern matching against ACTION_BOUNDARIES and known
+ * capability/prohibition registries.
+ */
+export function classifyAction(action) {
+    const normalized = action.toLowerCase().replace(/[_-]/g, ' ');
+    // Check against prohibited autonomy first (most restrictive)
+    for (const [, config] of Object.entries(PROHIBITED_AUTONOMY)) {
+        const keyword = config.name.toLowerCase().replace('auto-', '');
+        if (normalized.includes('auto') && normalized.includes(keyword)) {
+            return {
+                action,
+                boundary: 'AUTONOMOUS_ACTION',
+                is_observation: false,
+                is_autonomous: true,
+                justification: config.reason,
+                violates_invariant: config.violates_invariant,
+            };
+        }
+    }
+    // Check against self-management capabilities
+    for (const [, config] of Object.entries(SELF_MANAGEMENT_CAPABILITIES)) {
+        const keyword = config.name.toLowerCase();
+        if (normalized.includes(keyword)) {
+            return {
+                action,
+                boundary: 'OBSERVATION',
+                is_observation: true,
+                is_autonomous: false,
+                justification: `Allowed self-management capability: ${config.name}`,
+            };
+        }
+    }
+    // Classify by verb patterns
+    const hasReadVerb = ACTION_BOUNDARIES.read_operations.some(v => normalized.includes(v));
+    const hasWriteVerb = ACTION_BOUNDARIES.write_operations.some(v => normalized.includes(v));
+    const hasJudgmentVerb = ACTION_BOUNDARIES.judgment_operations.some(v => normalized.includes(v));
+    if (hasWriteVerb || hasJudgmentVerb) {
+        return {
+            action,
+            boundary: 'AUTONOMOUS_ACTION',
+            is_observation: false,
+            is_autonomous: true,
+            justification: 'Write or judgment operation requires human authorization',
+            violates_invariant: 5,
+        };
+    }
+    if (hasReadVerb) {
+        return {
+            action,
+            boundary: 'OBSERVATION',
+            is_observation: true,
+            is_autonomous: false,
+            justification: 'Read-only operation',
+        };
+    }
+    // Default: unknown actions require governance
+    return {
+        action,
+        boundary: 'GOVERNED_ACTION',
+        is_observation: false,
+        is_autonomous: false,
+        justification: 'Unknown action — requires explicit governance',
+    };
+}
+/**
+ * Check if an action is a pure observation (read-only, allowed).
+ */
+export function isObservation(action) {
+    return classifyAction(action).is_observation;
+}
+/**
+ * Check if an action is autonomous (forbidden without human approval).
+ */
+export function isAutonomous(action) {
+    return classifyAction(action).is_autonomous;
+}
+/**
+ * Check if a ProhibitedAutonomy key is in the prohibited list.
+ */
+export function isProhibitedAction(action) {
+    return action in PROHIBITED_AUTONOMY;
+}
+/**
+ * Validate that an action respects the human oversight boundary.
+ * Returns null if valid, or an error message if violated.
+ */
+export function validateActionBoundary(action, hasHumanAuthorization) {
+    const classification = classifyAction(action);
+    if (classification.is_observation) {
+        return null;
+    }
+    if (classification.is_autonomous) {
+        return (`Action "${action}" is prohibited. ${classification.justification}. ` +
+            `Violates ADR-005 Invariant ${classification.violates_invariant}.`);
+    }
+    if (classification.boundary === 'GOVERNED_ACTION' && !hasHumanAuthorization) {
+        return `Action "${action}" requires human authorization.`;
+    }
+    return null;
+}
+//# sourceMappingURL=adr-005-system-coherence-drift-self-governance.js.map