Manifest Graph Verification¶

Manifest graph verification extends the Structural Explainability manifest layer from single-repository validation to organization-level dependency validation.

It does not introduce a separate verifier product. It adds a graph pass to the existing se-manifest control plane so the organization can check whether its repository structure preserves the same distinctions its contracts require of Accountable Records.

Purpose¶

SE_MANIFEST.toml declares repository identity, class, layer role, dependencies, and provided artifacts.

manifest-schema.toml defines the allowed shape of those declarations.

data/schema/role-capability-map.toml binds manifest classes to role groups, role groups to verifier capability profiles, and role groups to graph-permission rules.

Manifest graph verification answers:

Does the repository graph preserve Structural Explainability boundaries?

The goal is to make cross-repository drift visible before release. Missing manifests, unresolved dependencies, dependency cycles, undeclared provided artifacts, interpretation leaks, direct theory bypasses, and duplicate formalization paths should become diagnostics instead of manual discoveries.

Non-goals¶

Manifest graph verification makes selected structural drift inspectable, diagnosable, and testable. It does not:

• replace validate-manifest
• replace repository-local tests
• replace Accountable Record stage validation
• prove that domain content is true
• prove that evidence is semantically adequate
• make drift impossible

Inputs¶

The graph verifier reads these control-plane artifacts.

Repository manifests¶

Each repository is expected to declare identity, role, dependencies, and provided artifacts.

[repository]
organization = "structural-explainability"
name = "example-repo"
class = "implementation"
kind = "python-package"
status = "active"
since = "2026"
summary = "Example repository."

[layer]
space = "implementation"
role = "verifier-implementation"

[depends]
required = [
    { repo = "accountable-record", kind = "semantic" },
]
optional = [
    { repo = "se-contract-kit", kind = "tooling" },
]

[provides]
artifacts = [
    "src/example",
]

A repository with no SE_MANIFEST.toml is not silently skipped. It emits SE.ORG.MISSING_MANIFEST.

Manifest schema¶

The graph verifier reads manifest-schema.toml for:

• known sections
• known fields
• known repository classes
• class-specific required sections
• dependency declaration shape
• provided artifact declaration shape

Role capability map¶

The graph verifier reads data/schema/role-capability-map.toml.

The role capability map provides:

• manifest class to role group bindings
• role group to graph-permission rules
• role group layer order
• semantic surface bucket requirements

The graph verifier consumes:

• role_groups
• graph_permissions
• layer_order
• surface_buckets

The Accountable Record stage verifier consumes:

• role_groups
• capability_profiles

Both tools read the same class-to-role binding. Neither redefines it locally.

Provided artifacts¶

The graph verifier checks declared provided artifacts against the repository tree or declared release surface.

For formalization results, manifests may declare per-artifact formalization status.

[provides.formalization.identity_regime_lower_bound]
kind = "lean-theorem-set"
status = "canonical"
symbols = [
    "IdentityRegime.lowerBound",
]

Formalization status belongs to the provided artifact, not to the whole repository.

Allowed statuses:

• canonical
• auxiliary
• transitional
• superseded

Dependency kinds¶

Each dependency edge has a kind.

Initial required kinds:

• semantic
• tooling

Reserved kinds:

• documentation
• test
• release
• provenance

All dependency edges must resolve. Only semantic edges participate in authority rules.

Tooling dependencies are real dependencies for installation and CI, but they do not confer semantic authority. For example, a theory repository may depend on se-contract-kit to run surface drift checks. That dependency should resolve, but it should not be interpreted as the theory repository deriving semantic authority from se-contract-kit.

Graph model¶

The graph verifier builds a directed dependency graph.

Nodes are repositories. Node attributes include:

• repository name
• repository class
• layer space
• layer role
• normalized role group
• repository status

Edges are declared dependencies. Edge attributes include:

• source repository
• target repository
• required or optional
• dependency kind
• optional version or reason metadata

The required semantic dependency graph is the authority graph used for cycle and layer-direction checks.

Diagnostic namespace¶

Manifest graph diagnostics use the SE.ORG.* namespace.

This mirrors the staged Accountable Record diagnostic pattern while keeping organization-level diagnostics separate from record-level diagnostics.

Examples:

SE.ORG.MISSING_MANIFEST
SE.ORG.UNRESOLVED_DEPENDENCY
SE.ORG.DEPENDENCY_CYCLE
SE.ORG.MISSING_PROVIDED_ARTIFACT
SE.ORG.CORE_DEPENDS_ON_DOMAIN
SE.ORG.THEORY_BYPASS

Diagnostic codes are part of the public conformance surface. They should be stable once released.

Graph invariants¶

Structural invariants¶

Semantic graph invariants¶

Classification invariants¶

Encoding agreement checks¶

Some checks compare two encodings of the same commitment.

Pattern:

Representation A and Representation B describe one commitment.
If they disagree, report drift.

Theory surface mirrors must expose these semantic buckets:

SURFACE_TYPES
SURFACE_PREDICATES
SURFACE_AXIOMS
SURFACE_THEOREMS
SURFACE_WITNESSES

A bucket may be empty, but it must exist.

The buckets are semantic roles, not Lean keyword categories. A def may be a predicate, witness, classifier, helper, constructor, or executable adapter. The author classifies public symbols by semantic role.

Role capability map¶

The role capability map is a versioned contract artifact, not helper config.

Path:

data/schema/role-capability-map.toml

Companion schema:

data/schema/role-capability-map.schema.toml

The map is internally separated into consumer-specific slices.

[schema]
schema_id = "se-role-capability-map-1"
version = "0.1.0"

[role_groups]
# manifest class -> role group

[capability_profiles]
# role group -> verifier and stage capabilities

[graph_permissions]
# role group -> semantic edge rules

The Accountable Record verifier reads:

• role_groups
• capability_profiles

The graph verifier reads:

• role_groups
• graph_permissions
• layer_order
• surface_buckets

Both share the same class-to-role binding.

Severity policy¶

Structural and semantic graph violations fail the build:

• SI01
• SG01
• SG02
• SG03
• SG04
• SG05
• SI02
• SI03
• SI04

Classification findings warn until release gate:

• CG01
• CG02

At release gate, warnings must either be resolved or explicitly accepted with a recorded reason.

This mirrors the Accountable Record authority decision: absence, emptiness, and opt-out are distinct states. An accepted exception should be recorded, not silently ignored.

Output¶

The command should emit both machine-readable and human-readable reports.

Recommended output paths:

data/export/org-graph-report.json
data/reports/org-graph-report.md

The report should include:

• repository count
• missing manifest list
• dependency graph summary
• required semantic graph summary
• dependency kind counts
• per-invariant pass/fail results
• diagnostics with repository context
• orphan list
• duplicate formalization list
• provided-artifact findings
• surface and traceability findings when enabled

CLI command¶

The graph pass should be exposed as an explicit command first.

se-manifest verify-graph

It should remain separate from validate-manifest --strict while the graph layer is new.

Later, strict validation may call both commands, or a release-gate command may run both.

se-manifest validate-manifest --strict
se-manifest verify-graph --strict

Placement and ownership¶

Ownership order:

• se-manifest-schema owns manifest structure, class-to-role mapping, role-to-capability mapping, and manifest graph validation.
• se-contract-kit owns reusable cross-encoding checks over formal-contract and theory artifacts.
• Theory repositories own their Lean surfaces and per-symbol bucket judgments.
• Accountable Record implementations consume the shared role capability map; they do not redefine it.
• Future Rust conformance checks consume the same map.

First implementation slice¶

The first slice should prove the mechanism before encoding every policy edge rule.

Scope:

• load all accessible repository manifests
• emit SE.ORG.MISSING_MANIFEST for absent manifests
• parse structured dependency entries
• distinguish required and optional dependencies
• distinguish semantic and tooling dependencies
• build the dependency graph
• validate SI01, SI02, SI03, and SI04
• emit JSON and Markdown reports

SI01, SI02, SI03, and SI04 do not require the full policy table. They are graph and structure facts.

Policy rules SG01 through SG05 should be switched on after role-capability-map.toml is populated and reviewed.

Release gate¶

Before v1.0.0, the graph verifier should confirm:

• all manifests are present or missing manifests are explicitly accepted
• all declared dependencies resolve
• the required semantic graph is acyclic
• semantic edge rules pass or have explicit accepted exceptions
• every class in manifest-schema.toml has a role group
• every role group has a capability profile
• every role group has a layer order
• every provided artifact exists
• formalization sources are classified
• theory surface buckets are present
• graph diagnostics are stable
• report outputs are generated

Change policy¶

Changes to manifest graph verification are contract-surface changes when they affect:

• dependency kind interpretation
• role group assignment
• capability profile derivation
• graph permission rules
• diagnostic codes
• release-gate severity
• required outputs

Each such change should answer:

1. Which consumer is affected?
2. Is the change backward-compatible?
3. Does this require fixture updates?
4. Does this require diagnostic-code changes?
5. Does this affect Python/Rust conformance?

Current status¶

Status: draft

The current implementation target is a first working graph slice. The map and schema are draft control-plane artifacts until the graph verifier consumes them and at least SI01, SI02, SI03, and SI04 are covered by tests.