Accountable Surfaces¶

Accountable Surfaces defines a portable convention for declaring repository and lifecycle surfaces where technical capability is not sufficient authority.

A surface is any repository or lifecycle object that may be changed, generated, executed, released, published, validated, or used as a public contract. A protected surface is a surface whose modification has authority-bearing consequences and therefore requires declared review and evidence.

Core model¶

The model is:

surface object
  -> surface roles
      -> authority requirements
          -> review requirements
              -> evidence requirements

A surface object describes what the surface is. A surface role describes the authority-bearing function that object performs in a repository or lifecycle context.

For example, pyproject.toml is a file. It may also carry multiple roles: project identity surface, package metadata surface, dependency boundary, Python version contract, optional dependency contract, tool configuration, public command surface, and release-affecting surface.

Normative keywords¶

This specification uses the following terms:

• MUST indicates a required rule.
• SHOULD indicates a recommended rule.
• MAY indicates an optional rule.
• MUST NOT indicates a prohibited rule.

Repository-first scope¶

The initial scope is repository-first. This specification is first validated against concrete software and Lean theory repositories.

The repository testbed validates the accountable-surfaces convention for tractable software and theory surfaces. It provides a conceptual bridge to higher-consequence lifecycle gates, where the structure may be necessary but is not sufficient.

Non-substrate status¶

Accountable surface manifests are operational governance artifacts. They are not substrate facts.

A manifest records declared authority boundaries, review requirements, evidence requirements, and permitted AI participation. It does not itself confer authority, legitimacy, obligation, or enforcement.