Defines the neutral constraints under which systems remain explainable, inspectable, and contestable without embedding interpretation.

Structural Explainability (SE) defines a neutral structural substrate for recording identity, structure, transformation, and change without embedding interpretation, authority, causality, or judgment.

Structural Explainability is not anti-interpretation; it is anti-implicit interpretation. It separates structural facts from downstream claims so interpretation and disagreement can remain explicit, attributable, and contestable over time.

• Identity & Persistence: A stable, inspectable identity is the prerequisite for all tracking and provenance. Identity is profile-relative: a single structural change might preserve identity under one profile, break it under another, or be entirely irrelevant under a third.
• Plural Systems: SE is built for independent architectures that share data without requiring a centralized authority, uniform naming, or a single forced ontology.

Within the core substrate, structure, transformation, persistence, and profile behavior may be recorded. Interpretation, explanation, evidence, authority, legitimacy, obligation, and enforcement remain outside the substrate unless attached through explicitly constrained downstream mechanisms.

Two strict architectural boundaries protect this substrate from leaking or collapsing into downstream application layers:

• Governance Boundary (GB): Prevents operational records from implicitly transforming into claims of absolute authority, legitimacy, obligation, or enforcement.
• Interpretation Boundary (IB): Ensures that external frameworks, explanations, and model interpretations remain attached as dynamic overlays rather than becoming hardcoded substrate semantics.

Downstream domains (e.g., law, infrastructure, agentic AI systems) consume the core substrate without redefining it. SE records the structural commitments of a system without deciding their ultimate meaning, enabling continuous cross-institutional coordination through persistent disagreement.

Some information systems make decisions that affect people, attribute claims to sources, record contested facts, or coordinate across institutions that disagree. When those systems collapse what should be distinct layers (what is structurally recorded, what is governed, what is interpreted, what is attested) into a single record, they lose the ability to represent the disagreement they exist to handle.

That collapse is often invisible until the system is challenged: in court, in audit, in appeal, in public review, or in cross-institutional reconciliation. By then, the records may already have committed to interpretations, authority claims, or judgments that the system never explicitly declared.

Structural Explainability defines the structural conditions under which this collapse can be prevented. It identifies what must be kept separate for an information system to remain durable, inspectable, and contestable under persistent disagreement:

• identity from graph continuity
• attribution from authority
• governance status from correctness
• evidence from interpretation
• dependency from validity
• explanation from proof
• record from judgment

SE does not replace domain vocabularies, standards, ontologies, or existing data systems. It constrains how systems implement them so that disagreement remains visible, attributable, and useful over time.

SE repositories use manifests to describe the repository's role, scope, dependencies, provided artifacts, validation expectations, governance, and traceability.

The SE manifest complements external metadata standards. Citation metadata belongs in CITATION.cff; software supply-chain metadata may use SPDX; software discovery metadata may use CodeMeta; research-object packaging may use RO-Crate.

Before looking at the tooling implementations, it is critical to see how SE's non-collapse discipline applies to the development environment itself. Just as the data substrate must not collapse history into interpretation, the operational environment must not collapse technical permissions into semantic authority.

A protected surface is one where the technical capability to change it is not the authority to change it.

Access control can grant the capability to perform an operation. It does not by itself establish that the capability is sufficient authority to modify a protected repository or lifecycle surface.

Accountable Surfaces records where capability is insufficient authority, and binds each crossing of that gap to required human review, supporting evidence, and permitted AI participation.

The authority manifest is self-protecting because the alternative is the collapse it exists to prevent: if an actor with technical capability can rewrite the authority declaration, capability has silently become authority.

SE repositories may additionally declare an authority manifest at .accountability/surfaces.toml, a sibling to SE_MANIFEST.toml.

Where SE_MANIFEST.toml declares structural role, scope, and dependencies, the authority manifest declares which repository and lifecycle surfaces are authority-bearing: surfaces a tool may be technically able to change but is not legitimately authorized to change without review.

This layer is operational, not substrate. It records declared review and evidence requirements for repository surfaces. It does not confer authority, legitimacy, obligation, or enforcement as substrate facts, and it respects the Governance Boundary. Enforcement is external and lives with se-admin tooling.

It applies SE's non-collapse discipline to the authority layer: technical capability is separated from legitimate authority, as record is separated from judgment. AI systems may assist review but may not satisfy human review authority.

The authority manifest is itself a protected surface. It requires human review and evidence of review, and AI authority over it is prohibited.

The project se-codeowners is an enforcement projection, not the source of authority. The authority declaration remains .accountability/surfaces.toml; se-codeowners renders one GitHub-specific expression of that declaration by mapping oversight roles to CODEOWNERS entries. This supports ordinary repository governance without collapsing technical write capability into legitimate review authority.

Accountable Agents extends the same non-collapse discipline to agentic AI systems.

An agent system may have technical capability: it may observe, interpret, propose, modify, execute, transmit, or self-alter depending on its product wrapper, execution environment, tools, and permissions. Some systems may also be configured near approval surfaces, such as merge, release, deployment, certification, or risk acceptance.

That capability is not authority. Responsibility cannot rest with an agent system; agent systems are tools. Authority and accountability remain with the people and institutions that use, build, release, deploy, authorize, operate, and review the systems.

This work is data-focused. It works alongside existing standards, security guidance, provenance models, model cards, product documentation, and research. It links them through claim-level records so that agent capabilities, affected surfaces, evidence sources, risk mappings, and accountability requirements can be inspected together.

Shared contract tooling supports packaging, validation, and distribution of machine-readable contract artifacts across SE repositories.

Accountable Record systems apply SE constraints to durable record structures.

The Accountable Record system repositories are in active development. They track main on their SE dependencies during this phase to allow the contract, domain systems, and verification implementations to co-evolve. Pinned versions follow once the contract stabilizes.

Accountable Record systems produce durable, inspectable records of decisions, relationships, claims, dependencies, sources, interpretations, or processes in ways that support inspection, contestation, audit, and continued use under disagreement.

These are application-layer repositories. They are real systems, not demonstrations, built to use ordinary domain vocabularies while preserving the structural distinctions required for accountable verification. These systems are organized as domain record systems, jurisdiction-specific specializations, and verification implementations.

Domain record systems implement the Accountable Record contract using ordinary domain vocabularies.

These repositories define general domain profiles, packages, mappings, record types, fixtures, and expected reports. They are not limited to one jurisdiction, institution, dataset, or source system.

Verification tools consume contracts, layouts, and conformance metrics to guarantee boundaries remain cleanly separated under load.

Structural Explainability does not replace domain ontologies or standards. Domain systems may use Akoma Ntoso, LegalRuleML, other OASIS open standards, FAIR principles, CIDOC-CRM, schema.org vocabularies, or other domain standards.

Verification checks whether a system's use of its chosen standards preserves the distinctions needed for accountable representation under persistent disagreement. It does not decide truth, legal correctness, civic authority, institutional legitimacy, or final domain meaning.

flowchart TD

  %% --- Theory Layer ---
  subgraph T[Theory Layer]
    NS[neutral substrate]
    TR[transformation]
    PE[persistence]
    IR[identity regimes]
    SET[structural explainability]
  end

  %% --- Boundary Specs ---
  subgraph B[Boundary Specs]
    GB[governance boundary]
    IB[interpretation boundary]
  end

  %% --- Contract / Governance ---
  subgraph G[Contract and Governance]
    FC[se-formal-contract]
    C[se-constitution]
    A[se-admin]
  end

  %% --- Operational Core ---
  subgraph O[Operational Core]
    K[se-kernel]
    M[se-mapspec]
    R[se-regimes]
    MAP[se-mapping-*]
    GOV[se-govsrc-*]
  end

  %% --- Accountable Record Systems ---
  subgraph ARS[Accountable Record Systems]
    AR[accountable-record]
    JR[judicial-record]
    CR[civic-record]
    JRS[Supreme Court specialization]
  end

  %% --- Verification Implementations ---
  subgraph V[Verification Implementations]
    ARPY[accountable-record-py]
    JRPY[judicial-record-py]
    CRPY[civic-record-py]
  end

  NS --> FC
  TR --> FC
  PE --> FC
  IR --> FC
  SET --> FC

  GB --> C
  IB --> C

  FC --> C
  C --> A

  A --> K
  A --> M
  A --> R
  A --> MAP
  A --> GOV

  K --> AR
  M --> AR
  R --> AR

  AR --> JR
  AR --> CR
  JR --> JRS

  ARPY --> AR
  JRPY --> JR
  CRPY --> CR

  IB -.-> AR
  IB -.-> JR
  IB -.-> CR

  GB -.-> AR
  GB -.-> JR
  GB -.-> CR

All repositories in this diagram declare an SE_MANIFEST.toml conforming to se-manifest-schema, which has no upstream SE dependencies.

Structural Explainability consists of a small formal core (SE-100: Neutrality; SE-200: Identity Regimes) and a parallel stewardship track addressing governance over time. The stewardship track examines how neutral systems are defined, audited, stressed, and repaired in real institutional contexts.

The two formal papers provide theoretical justification for foundational specifications. They are explanatory rather than normative (they describe what must be true for such systems to work, not what people should believe or do).

• To understand the justification, start with the papers.
• To understand the architecture, start with the specifications.
• To verify formal coherence, consult the Lean formalizations.
• To consume stable definitions, use the formal contract artifacts.
• To validate repositories, use the manifest and conformance tooling.