Agent Authority Standards Institute the standard that can prove what it says

Lifecycle of a revision

The discipline the Institute already runs, written down as policy.

This page is not aspiration. Each step below has been executed at least once, and each execution left a verifiable record — the seals are on the version history, re-derivable from your browser, keyless.

The cycle

  1. Propose. A change begins as a written proposal — the problem first, then the change (the GAP register; the process rides the change-governance path).
  2. Review. The steward reviews the proposal against the charter's principles and records the outcome with reasons on the proposal of record.
  3. Version. An accepted change lands against the specification text. Normative wording changes bump the draft version with a recorded rationale; editorial changes do not.
  4. Seal. The revision is emitted through a governed flow and sealed into a tamper-evident chain — an attributable act an independent party can re-derive without the Institute's cooperation. Sealing is not publishing; a staged draft is sealed and stays labeled a staged draft.
  5. Publish. The revision becomes the living text at /standard/text and gains its row on the version history — date, summary of change, chain id, and an in-browser verify chip.
  6. Archive-prior. The superseded revision is preserved as a version of record — never deleted, never silently rewritten.

Frozen revision URLs

Every sealed revision is frozen at a per-revision URL: /standard/<rev>/ (today: /standard/r1/). A frozen URL has three properties, each of which is checkable rather than asserted:

  • The bytes do not drift. The frozen artifact (/standard/<rev>/frozen.html) serves exactly the sealed bytes; its sha-256 is printed beside it, so any reader can hash what they received and compare. The status line shown above a frozen revision is serve-time chrome — it can change from current to superseded without touching the artifact.
  • Superseded is stated, never redirected. When a revision is superseded, its frozen URL keeps serving the same bytes under a superseded banner that names the successor. A citation to a superseded revision keeps resolving to exactly what it cited.
  • Unknown fails honestly. A revision that does not exist answers 404. This site never substitutes the current text for a missing revision — a citation either resolves to what it names or it fails in the open.

Deprecation policy

Stated plainly: a revision is never deleted. Superseding a revision changes its label, not its availability — it stays citable at its frozen URL, under its banner, indefinitely. The version history records the succession. There is no removal path in the policy, and none in the tooling.

Cryptographic agility

Seals are content hashes. The specification's own agility posture (§10 of the text, GAA-AGIL-1) applies to the Institute's practice here: hash identifiers carry an explicit namespace so the hash function can rotate by policy — new entries adopt the successor namespace while prior entries remain verifiable under theirs. The hash can rotate; the record survives. A migration is an addition to the record, not a rewrite of it.

What has actually run

Once, end to end, and honestly labeled as once: the canonical itemized edition (r1) went propose → review → version → seal (chain 00ms0lp62r-7bfe02863a4583ce, re-derivable on the version history) → staged publication on this site → prior edition archived as a version of record. This page freezes that discipline as the policy for every revision after it.