Conformance¶

This document defines draft conformance expectations for accountable surface manifests and tools.

Conformance is structural. A conforming manifest records authority-bearing surfaces, role-specific review requirements, role-specific evidence requirements, and permitted AI authority. It does not confer authority, legitimacy, obligation, or enforcement.

Conformance classes¶

This specification defines four draft conformance classes:

• manifest conformance;
• profile conformance;
• validator conformance;
• enforcement-mapping conformance.

A repository may conform at one or more classes.

Manifest conformance¶

A conforming .accountability/surfaces.toml manifest MUST declare:

• schema_version;
• repository identity;
• repository profile;
• at least one protected surface;
• one object_kind for each surface;
• one or more roles for each surface;
• review requirements for each role;
• evidence requirements for each role;
• maximum AI authority for each role.

A conforming manifest MUST declare .accountability/surfaces.toml itself as a protected surface.

AI authority over .accountability/surfaces.toml MUST be prohibited.

A conforming manifest MUST NOT treat technical capability as sufficient authority for a protected surface.

A conforming manifest MUST keep object kind and role kind separate:

• object_kind describes what the surface is;
• role.kind describes the authority-bearing function the surface performs.

A conforming manifest MUST NOT place the same term in object-kind and role-kind positions unless the specification explicitly defines separate object and role forms for that term.

Multi-role conformance¶

A conforming manifest MAY assign multiple roles to one surface.

A multi-role surface MUST be represented as one surface object with one object_kind and multiple role entries.

For a multi-role surface:

• review requirements compose by union;
• evidence requirements compose by union;
• downstream effects compose by union;
• effective AI authority is the most restrictive applicable value.

Duplicate declarations for the same surface are non-conforming unless the declarations are explicitly scoped by non-overlapping paths, generated outputs, commands, lifecycle stages, or another specification-defined scope boundary.

Review conformance¶

A conforming manifest MUST distinguish declared review requirements from satisfied review requirements.

A declared review requirement is not satisfied merely because it appears in the manifest.

AI systems MAY assist review.

AI systems MUST NOT satisfy human review authority.

A human review requirement is satisfied only by attributable review from a human reviewer with the required reviewer authority.

Evidence conformance¶

A conforming manifest MUST distinguish declared evidence requirements from satisfied evidence requirements.

A declared evidence requirement is not satisfied merely because it appears in the manifest.

Satisfied evidence SHOULD identify:

• evidence kind;
• evidence source;
• producing actor or system;
• timestamp or run identifier when available;
• related surface;
• related role;
• related review requirement;
• reviewer authority when evidence satisfies human review.

Evidence that satisfies a human review requirement MUST identify reviewer authority.

AI-generated summaries, comments, or review notes MAY support a human reviewer. They MUST NOT satisfy the human review requirement.

AI authority conformance¶

A conforming manifest MUST use AI authority levels according to the authority vocabulary.

AI authority levels are named policy bundles over permission kinds.

The following sensitive permissions MUST be excluded from every default AI authority bundle:

• approve;
• merge;
• release;
• publish;
• deploy;
• bind;
• revoke;
• delegate.

These sensitive permissions MAY be granted only by explicit surface-specific rules that require human review and supporting evidence.

prohibited is not an AI authority level in the monotone authority ladder. It is a distinct denial state.

Profile conformance¶

A conforming profile MUST define:

• the profile name;
• intended repository or lifecycle scope;
• required protected surfaces;
• common surface roles;
• minimum review requirements;
• minimum evidence requirements;
• AI authority defaults;
• profile-specific validation expectations.

A profile MUST NOT weaken the manifest self-protection rule.

A profile MUST NOT allow AI authority to satisfy human review authority.

A profile MAY add stricter rules than the base specification.

Validator conformance¶

A conforming validator SHOULD check manifest structure and declared obligations.

A conforming validator MUST distinguish declared obligations from satisfied obligations.

A conforming validator SHOULD report at least:

• missing authority manifest;
• missing manifest self-protection;
• non-prohibited AI authority over the authority manifest;
• missing surface role declarations;
• missing review requirements;
• missing evidence requirements;
• duplicate surface declarations without explicit scope;
• unknown object kinds;
• unknown role kinds;
• unknown review kinds;
• unknown evidence kinds;
• unknown AI authority levels;
• use of sensitive permissions in default AI authority bundles;
• declared obligations that are not yet satisfied.

A validator MAY support multiple modes, such as:

• structure-only validation;
• strict vocabulary validation;
• satisfied-obligation checking;
• enforcement-mapping checking.

Enforcement-mapping conformance¶

A conforming enforcement mapping SHOULD map accountable surface declarations to existing enforcement substrates rather than replacing them.

Potential mapping targets include:

• CODEOWNERS;
• branch protection;
• OPA/Rego;
• SLSA;
• in-toto;
• Sigstore;
• se-admin tooling.

A mapping is conforming only when it preserves the distinction between:

• declared authority boundary;
• technical capability;
• required review;
• required evidence;
• satisfied review;
• satisfied evidence;
• enforcement mechanism.

A mapping MUST NOT treat the existence of an enforcement mechanism as proof that the declared authority requirement has been satisfied.

Non-conformance examples¶

The following are non-conforming:

• a manifest that does not declare itself as protected;
• a manifest that allows AI authority to modify itself;
• a manifest that gives AI systems authority to satisfy human review;
• a manifest that collapses object kinds and role kinds;
• a manifest that grants sensitive permissions through a default AI authority bundle;
• a manifest that declares evidence requirements but treats them as already satisfied;
• a validator that reports only declared obligations while presenting them as satisfied obligations;
• an enforcement mapping that treats access-control capability as sufficient authority.

Draft status¶

This conformance model is draft v0.1.0.

The first conformance targets are:

• accountable-surface-spec;
• accountable-authority-vocabulary;
• accountable-surface-vocabulary;
• accountable-review-vocabulary;
• accountable-evidence-vocabulary;
• se-theory-reference-kit;
• the five Lean theory repositories.

The portability claim remains deferred until the convention has been tested outside the initial SE/Python/Lean repository family.