CAT-ALIGN-001: align MAM with controlling Veraxis category thesis

[veraxis-protocol]

Scope

Documentation only, additive. One section added to README.md after the opening authority-path sentence. Nothing removed or reworded.

• README.md — 14 insertions, 0 deletions

Why

This repository has the single strongest authority sentence in the org's public surfaces:

Memory is not passive context. Memory is delegated influence over future behavior. If memory changes what an agent may believe, output, or do, memory is part of the authority path.

That is correct and worth keeping. Unqualified, though, it can be read as memory creating authority. The added section draws the line:

"Memory is part of the authority path" means memory can carry authority forward, not that it can create it. MAM governs whether a memory is admissible for reliance; it does not interpret governing sources, perform institutional admission, or originate the institutional authority a memory may reference.

It also states that an Authorization Evidence Pack is a downstream artifact rather than the origin of authority — consistent with what docs/architecture/03-cryptographic-custody-chain.md already says, that this repository implements the linkage primitive making EEP and AEP accountable to the Session MAP rather than full EEP/AEP protocol storage.

Census classification: B — SUPPORTING. AEP terminology and authority-path positioning appear here, so the thesis link applies; the existing scoping already agrees with the thesis and is quoted rather than altered.

What is explicitly preserved

• The opening authority-path statement, verbatim
• All eight production invariants
• The benchmark envelope (~33 ns/op, 0 B/op, 0 allocs/op; lineage compiler ~245 ns/op) and the allocation-free hot-path statement
• Repository layout, custody chain Memory → MAP → EEP → AEP → MCR, release notes and staging language

Claim impact

None. No maturity, readiness, benchmark or adoption claim is made, broadened or narrowed. No enterprise adoption is asserted for any party.

No runtime change

No Go code, proto, schema, deployment manifest, fixture or test was changed. The diff touches one Markdown file.

Validation

Ran this repository's CI gates locally with Go 1.24.7 (workflow uses 1.20; the change adds no Go, so toolchain version cannot affect the result):

Gate	Result
go build -v ./...	exit 0
go test -v ./...	ok tests/adversarial, ok tests/integration, ok tests/unit; remaining packages have no test files

• Base SHA: 9f9b8711c7edd811e94c1769f824053553af125f
• Head SHA: bfc4d1d151a090ab94cc9ff0e77be99d4a5adf30

Controlling thesis

veraxis-protocol/institutional-continuity#2 — Veraxis Category Thesis v1.0. Canonical location after merge: https://github.com/veraxis-protocol/institutional-continuity/blob/main/THESIS.md

---

Generated by Claude Code

[veraxis-protocol]

CI is red, and it is not this PR's failure

Failing check: build — run 34285315337

veraxis-memory-admissibility/pkg/merkle: cannot compile Go 1.22 code
veraxis-memory-admissibility/cmd/mam-bench: cannot compile Go 1.22 code
veraxis-memory-admissibility/benchmarks/axis_fixtures: cannot compile Go 1.22 code
##[error]Process completed with exit code 1.

Why it isn't this PR's. It is a toolchain mismatch on the base branch:

• go.mod line 3 declares go 1.22
• .github/workflows/go.yml line 22 pins go-version: '1.20'

A Go 1.20 toolchain cannot compile a module that declares 1.22. This fails for every push and every pull request against main, independent of content.

This PR's entire diff is README.md (git diff --name-only origin/main...HEAD → README.md, and nothing else). It touches no Go file, no go.mod, and no workflow.

Locally, with Go 1.24.7, both gates pass on this branch:

• go build ./... → exit 0
• go test ./... → ok tests/adversarial, ok tests/integration, ok tests/unit

No fix ported, and why. The fix is one line — raise go-version in the workflow to 1.22 or later, or lower the go.mod directive. Either is a CI/toolchain change, not category positioning, and falls outside the bounded documentation scope authorized by work order CAT-ALIGN-001, whose first guardrail is no runtime or build-behavior changes. I am not widening this PR to carry it unasked. It is recorded in the CAT-ALIGN-001 census and raised with the owner; bumping the workflow is a small, clean, separate PR whenever the owner wants it.

No re-run. This is a deterministic version-directive mismatch, not a flake. Re-running the same job on the same commit with the same pinned toolchain would fail identically.

---

Generated by Claude Code