diff --git a/CAT-ALIGN-001-EXECUTION-REPORT.md b/CAT-ALIGN-001-EXECUTION-REPORT.md new file mode 100644 index 0000000..3272281 --- /dev/null +++ b/CAT-ALIGN-001-EXECUTION-REPORT.md @@ -0,0 +1,101 @@ + + + +# CAT-ALIGN-001 Execution Report + +**Work order:** CAT-ALIGN-001 — Veraxis Category Thesis Freeze and Public-Surface Alignment +**Owner:** Arkadiy Miteiko +**Executed:** 2026-09-08 +**Executor session:** `session_01Pkw68qW3iRaeJsiMPBEPvW` + +STATUS: **CAT_ALIGN_PR_SET_CREATED** + +THESIS PR: https://github.com/veraxis-protocol/institutional-continuity/pull/2 +THESIS BASE SHA: `549430974b9511261e997f8f67febb7ad99b503a` +THESIS HEAD SHA: see the PR head; the thesis branch carries THESIS.md, the perception gate, the +README deconfliction, the website patch document, the census and this report. + +REPOS CENSUSED: 14 +REPOS MODIFIED: 10 +REPOS NOT MODIFIED: 4 + +## Per-repository record + +| Repository | Base SHA | Branch | Head SHA | Files changed | Tests / checks | PR | Status | +|---|---|---|---|---|---|---|---| +| `institutional-continuity` | `549430974b9511261e997f8f67febb7ad99b503a` | `cat-align-001-category-thesis` | see PR | `THESIS.md`, `governance/CATEGORY-PERCEPTION-GATE.md`, `README.md`, `WEBSITE-CATEGORY-PATCH.md`, `CATEGORY-SURFACE-CENSUS.md`, `CAT-ALIGN-001-EXECUTION-REPORT.md` | `tools/validate_repo.py` PASS before and after | [#2](https://github.com/veraxis-protocol/institutional-continuity/pull/2) | PR created | +| `veip-spec` | `b7bae309cd39b6be2f1669aff75c4feb9cf18668` | `cat-align-001-category-thesis` | `26db2538f1913637a242b0730de6866f5943b408` | `README.md` (+20) | `make schema` PASS; `make check` red on `main` before and after (pre-existing missing `LICENSE.md`) | [#1](https://github.com/veraxis-protocol/veip-spec/pull/1) | PR created | +| `veip-sdk` | `40bcb5708c8e3aadcb0e31d3190824ddc33f8fce` | `cat-align-001-category-thesis` | `6d1d65e77868a8a0516cff0cf9513785e15dd6c9` | `README.md` (+20) | `make check` PASS (the gate CI runs); pytest unavailable locally | [#1](https://github.com/veraxis-protocol/veip-sdk/pull/1) | PR created | +| `veip-verifier-core` | `e8b985920b60ba74f2e0e014ee107a5c4937b1fc` | `cat-align-001-category-thesis` | `6df68f5667ea283b59d5e9cad51ae9cd41bc4b12` | `README.md` (+18) | `make check` PASS before and after; pytest unavailable locally | [#1](https://github.com/veraxis-protocol/veip-verifier-core/pull/1) | PR created | +| `veip-registry` | `a0b70452d14c0b29da500d53714ae215b09bc43e` | `cat-align-001-category-thesis` | `f91b474a2202c1124920cedb1286d6f0c9c7101f` | `README.md` (+16) | `make check` PASS before and after; pytest unavailable locally | [#1](https://github.com/veraxis-protocol/veip-registry/pull/1) | PR created | +| `Institutional-Compiler` | `c3d986229e2d7874a30a318981f5045e3f793236` | `cat-align-001-category-thesis` | `5a7813b6488f7568f0379afedfe0d73996c85634` | `README.md` (+23) | claims-discipline 51 passed; ruff, format, strict mypy PASS; `make verify` PASS (manifest INCOMPLETE preserved); `make falsify` 4/4; **full suite 1743 passed, 1 declared skip, 0 failed** | [#44](https://github.com/veraxis-protocol/Institutional-Compiler/pull/44) | PR created | +| `AuthContract` | `6c677aec730bff79dfc60a88d1721564000ad111` | `cat-align-001-category-thesis` | `1dfeef7267d66fb8dc16bc37de6aedd62906c133` | `README.md` (+16) | `make test` **343 passed**; `make falsify` 4/4; `make no-network` PASS | [#16](https://github.com/veraxis-protocol/AuthContract/pull/16) | PR created | +| `runtime-admissibility-experiment` | `ded0d0d0d831512556ba14c5b692cebb553c7a83` | `cat-align-001-category-thesis` | `de5f0d0a33b4e131e8efa785055519b7e4ce8315` | `README.md` (+14) | `pytest` 10 passed before and after; scenario CLI runs clean | [#1](https://github.com/veraxis-protocol/runtime-admissibility-experiment/pull/1) | PR created | +| `RAED` | `471f81dcd6a468a5f8b6b6cb95c4b06b4182896a` | `cat-align-001-category-thesis` | `b979a7318e8284f06b218f530ac7979382917e29` | `README.md` (+12) | `gofmt` clean; `go vet ./...` clean; `go test ./...` ok | [#1](https://github.com/veraxis-protocol/RAED/pull/1) | PR created | +| `Veraxis-Memory-Admissibility-Management-MAM-` | `9f9b8711c7edd811e94c1769f824053553af125f` | `cat-align-001-category-thesis` | `bfc4d1d151a090ab94cc9ff0e77be99d4a5adf30` | `README.md` (+14) | `go build ./...` exit 0; `go test ./...` ok across adversarial, integration and unit suites | [#1](https://github.com/veraxis-protocol/Veraxis-Memory-Admissibility-Management-MAM-/pull/1) | PR created | +| `Institutional-Compiler-Review-Ledger` | `713381f866798a950e02cf19c3270e145af94369` | — | — | none | — | — | Not modified (Class C, frozen evidence ledger) | +| `white-papers` | `584a9d3393b3183a2ed985fbb6ca6caf466b84cb` | — | — | none | — | — | Not modified (Class C, released PDF) | +| `Open-Audit-Mission` | empty repository | — | — | none | — | — | Not modified (Class D, no commits) | +| `awesome-mcp-servers` | not cloned | — | — | none | — | — | Not modified (Class D, upstream fork) | + +## Website + +- Exact source repo identified? **NO** +- Modified? **NO** +- WEBSITE-CATEGORY-PATCH.md location: [`WEBSITE-CATEGORY-PATCH.md`](WEBSITE-CATEGORY-PATCH.md) in + this repository. + +All 14 reachable repositories were searched for `index.html`, any `.html`, `CNAME`, `_config.yml`, +`netlify.toml`, `vercel.json`, `next.config.*`, `astro.config.*` and GitHub Pages deployment +workflows. Zero matches. A read of `https://veraxis.io` was refused by the network egress policy +(`EGRESS_BLOCKED`) and was not retried or routed around, so current site copy could not be captured +and is left explicitly blank in the patch document rather than reconstructed. + +No unrelated repository was modified as a substitute. + +## Perception surface + +**Old failure mode.** Evidence artifacts were the most legible thing about Veraxis. The VEIP family +foregrounded execution authorization and Evidence Pack emission with no statement of what must be +established upstream; OIC — the component that addresses that upstream problem — never named the +field it belongs to; and ICI's badge presented itself as the parent category. An external reader +given any one of those surfaces would reasonably conclude that Veraxis is an evidence-infrastructure +company. Two external events showed exactly that: an independent AI-assisted evaluation of VEIP that +centered on the Authorization Evidence Pack, and an executive discussion that opened on +authority/permission computation and drifted to AEP security and evidence. + +**New intended hierarchy.** Field: Open Institutional Computation. Missing computation: institutional +authority computation. OIC upstream; VEIP the downstream execution-integrity boundary; enforcement +runtimes consumers; Evidence Pack / AEP a downstream artifact; ICI the reference end-to-end +continuity architecture within the field, not a competing parent. THESIS.md is the controlling +source and every aligned repository links to it. + +**Remaining known inconsistencies.** Recorded in +[CATEGORY-SURFACE-CENSUS.md](CATEGORY-SURFACE-CENSUS.md): the `spec/CATEGORY-CONSTITUTION.md` title +(requires a normative successor under `spec/CHANGE-CONTROL.md` — owner decision), the unresolved +veraxis.io source, a pre-existing red CI gate in `veip-spec`, a truncated sentence in the +`veip-registry` README, the unassessed white-paper PDF, and component names (`VICCP`, `ZTL`, +`RegSpine`, `CAGE`, `OAM`) with no reachable repository in this account. + +## Negative assertions + +- runtime semantics changed: **FALSE** +- schemas changed: **FALSE** +- benchmark evidence changed: **FALSE** +- historical releases rewritten: **FALSE** +- implementation maturity claims broadened: **FALSE** + +Additionally: no test expectation was changed to accommodate messaging. Where a test blocked the +standard placement — `AuthContract`'s developer-language ordering lock — the documentation moved and +the test stood. No enterprise adoption is asserted for Google Cloud, Backbase, Fujitsu or any other +party. No normative specification was altered. No branch was merged, and no default branch was +written to. + +## Final verdict + +**CAT_ALIGN_PR_SET_CREATED** + +Not `CAT_ALIGN_COMPLETE_VERIFIED`: every PR is open and unmerged, which is the work order's default +disposition. THESIS.md exists, the VEIP family is aligned, ICI no longer claims the parent category, +and OIC carries its category-role link — but completion depends on merge, and on the owner decision +recorded for `spec/CATEGORY-CONSTITUTION.md` and the veraxis.io source. diff --git a/CATEGORY-SURFACE-CENSUS.md b/CATEGORY-SURFACE-CENSUS.md new file mode 100644 index 0000000..01efa3a --- /dev/null +++ b/CATEGORY-SURFACE-CENSUS.md @@ -0,0 +1,80 @@ + + + +# Category Surface Census — CAT-ALIGN-001 + +**Controlling source:** [THESIS.md](THESIS.md) — Veraxis Category Thesis v1.0 +**Date:** 2026-09-08 +**Scope:** every repository reachable by the executing account under `veraxis-protocol` (14 total, +enumerated from the account's repository list; the listing reported no further pages). + +## Method + +For each repository: the working tree was cloned and inspected — `README.md`, category and +architecture documents, terminology documents, and public landing documentation — and searched +case-insensitively across all Markdown and text files for the terms `category`, +`Institutional Computation`, `Institutional Continuity`, `AI governance`, `governance layer`, +`authority`, `authorization`, `Evidence Pack`, `AEP`, `VEIP`, `OIC`, `protocol`, and `trust`. + +Repositories were then classified: + +- **A — CORE:** receives the standard role block now. +- **B — SUPPORTING:** links to THESIS.md where category positioning appears. +- **C — HISTORICAL/EXPERIMENTAL:** history preserved; historical claims not rewritten for consistency. +- **D — IRRELEVANT/FORK:** no action. + +No repository was rewritten merely for consistency. + +## Census + +| Repo | Class | Current positioning before CAT-ALIGN-001 | Conflict found? | Change made? | Reason | PR | Claim-impact assessment | +|---|---|---|---|---|---|---|---| +| `institutional-continuity` | A | Badge read `Category: ICI`, positioning ICI as the parent category | **Yes** — competing parent category | Yes — added THESIS.md and the perception gate; replaced the category badge with a field badge plus an architecture badge; added a placement section | Controlling source lives here; ICI must read as an architecture within the field, not as the field | [#2](https://github.com/veraxis-protocol/institutional-continuity/pull/2) | None. Nine-node chain, eight joins, invariants, ICTS and all claim ceilings unchanged; every implementation remains `NOT_EVALUATED` | +| `veip-spec` | A | Deterministic execution-control standard; execution authorization and evidence packaging foregrounded | Yes — no upstream boundary stated; readable as originating authority | Yes — role block plus an architectural-position subsection | Highest-risk surface for category collapse toward Evidence Packs | [#1](https://github.com/veraxis-protocol/veip-spec/pull/1) | None. Normative spec, scope, licensing, schemas, invariants, versioning untouched; "Evidence Pack" schema terminology preserved | +| `veip-sdk` | A | Architecture model began at `AI System → Action Proposal → VEIP Authorization Gate` | Yes — chain started at the gate, nothing stated what must be true upstream | Yes — role block plus an Upstream Boundary section before the architecture model | An authority envelope is an input; the SDK does not originate it | [#1](https://github.com/veraxis-protocol/veip-sdk/pull/1) | None. Existing scope sections, invariants and version bindings preserved | +| `veip-verifier-core` | A | Careful about what it is not, but silent on what a PASS establishes | Yes — a PASS was over-readable as upstream validation | Yes — role block plus "What a PASS does and does not establish" | Verifier output is the easiest artifact in the stack to over-read | [#1](https://github.com/veraxis-protocol/veip-verifier-core/pull/1) | Restrictive only. Existing verifier claim ceiling preserved, not widened | +| `veip-registry` | A | Already stated it is not a governance authority and not a centralized global registry | Partial — correct boundaries, no upstream reason given | Yes — role block plus the registry authority boundary | Custody of evidence is not legitimacy of authority | [#1](https://github.com/veraxis-protocol/veip-registry/pull/1) | None; restrictive in effect | +| `Institutional-Compiler` | A | Opened on status, bootstrap date and governing design; field never named | Yes — the upstream component was the least placeable surface | Yes — role section near the top | Inverted dependency: downstream surfaces were easier to recognize than the upstream one | [#44](https://github.com/veraxis-protocol/Institutional-Compiler/pull/44) | None. `BOUNDED_REFERENCE_IMPLEMENTATION`, Gate F/G figures, twelve exclusions, OIC-Bench `TARGET - NOT MEASURED` rows, STATUS/CLAIMS/capability matrix all unchanged | +| `AuthContract` | A | Developer-workflow framing under an owner-approved language freeze | Partial — receipt behavior over-readable as originating authority | Yes — role block placed **after** `Current status`, below `## Quick start` | `docs/DEVELOPER-LANGUAGE.md` and `tests/test_veip.py` forbid deep ontology vocabulary before Quick start; placement moved rather than changing the test | [#16](https://github.com/veraxis-protocol/AuthContract/pull/16) | None. TRL 4 / experimental status and the full "does not currently claim" list preserved verbatim | +| `runtime-admissibility-experiment` | A | Static authorization vs runtime admissibility, formally stated | Partial — `RA(x,t)` over-readable as defining institutional authority | Yes — role block stating `A_t` is an input | Research into the runtime currentness/admissibility boundary inside the field | [#1](https://github.com/veraxis-protocol/runtime-admissibility-experiment/pull/1) | None. No equation, predicate, scenario or result altered | +| `RAED` | B | Semantic memory substrate; core invariant is a field-level non-collapse rule | No conflict | Yes — role block plus thesis link | Category positioning appears ("It is the layer that…"), so the link applies | [#1](https://github.com/veraxis-protocol/RAED/pull/1) | None. CLAIMS, LIMITATIONS, CONFORMANCE, benchmarks, design targets untouched | +| `Veraxis-Memory-Admissibility-Management-MAM-` | B | "Memory is part of the authority path"; AEP appears in the custody chain | Partial — authority-path sentence over-readable as memory creating authority | Yes — role block bounding the authority-path claim and placing AEP downstream | AEP terminology and authority positioning appear here | [#1](https://github.com/veraxis-protocol/Veraxis-Memory-Admissibility-Management-MAM-/pull/1) | None. Production invariants, benchmark envelope and release notes unchanged | +| `Institutional-Compiler-Review-Ledger` | C | Adjudication and diagnostic evidence records; zero category-term hits | No | **No** | Frozen evidence ledger. Rewriting historical records for messaging consistency is forbidden by this work order | — | None; untouched | +| `white-papers` | C | Single released PDF (`Veraxis White Paper v1.2.pdf`); no editable Markdown surface | Not assessable — binary released artifact | **No** | Released artifact; not rewritten. Any category correction belongs in a successor paper version | — | None; untouched | +| `Open-Audit-Mission` | D | Repository is empty (clone reported no commits) | No | **No** | No surface to patch | — | None | +| `awesome-mcp-servers` | D | Upstream fork, not Veraxis positioning | No | **No** | Fork of third-party content | — | None | + +**Totals:** 14 censused, 10 modified, 4 not modified. + +## Remaining known inconsistencies + +These are recorded rather than fixed, each for a stated reason. + +1. **`spec/CATEGORY-CONSTITUTION.md` is titled "ICI Category Constitution".** With the README now + presenting ICI as an architecture within Open Institutional Computation, the normative spec still + uses "category" for ICI. Reconciling it is a **material normative change** under + [spec/CHANGE-CONTROL.md](spec/CHANGE-CONTROL.md) and requires a successor artifact with a full + change record. It was deliberately not changed by README-adjacent prose, per the work order's + guardrail against altering released specs by prose alone. **Owner decision required.** +2. **veraxis.io source is unresolved.** Not present in any reachable repository, and the live site + is unreachable from this environment. See [WEBSITE-CATEGORY-PATCH.md](WEBSITE-CATEGORY-PATCH.md). +3. **`veip-spec` CI is red on `main`, pre-existing.** `make check` requires both `LICENSE` and + `LICENSE.md`; only `LICENSE` exists. Unrelated to category positioning and outside this work + order's bounded documentation scope, so not fixed. Expect the veip-spec PR to inherit that + failure. +4. **`Veraxis-Memory-Admissibility-Management-MAM-` CI is red on `main`, pre-existing.** A + toolchain mismatch: `go.mod` declares `go 1.22` while `.github/workflows/go.yml` pins + `go-version: '1.20'`, so the `build` job fails with `cannot compile Go 1.22 code` on every push + and pull request regardless of content. Locally, with Go 1.24.7, `go build ./...` and + `go test ./...` both pass. The fix is a one-line workflow bump, which is a CI/toolchain change + rather than category positioning and therefore outside this work order's scope. Not fixed here. + +5. **`veip-registry` README ends mid-sentence.** The "Relationship to veip-spec" section reads + "The canonical Evidence Pack schema originates in:" with nothing following. Pre-existing and + unrelated to category positioning; not fixed. +6. **`white-papers` v1.2 PDF has not been assessed against the thesis.** Binary released artifact; + assessing and, if needed, correcting it belongs to a successor paper version, not to this work + order. +7. **Component names `VICCP`, `ZTL`, `RegSpine`, `CAGE` and `OAM`** appear in the ICI README's + reference-primitive table but have no reachable repository in this account. Their public + surfaces, if any exist elsewhere, were not censused. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ed28cc6..c3ceb0a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,7 +19,8 @@ A good contribution makes the system: Read: -1. `spec/CATEGORY-CONSTITUTION.md` +1. `spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md` (current; supersedes + `spec/CATEGORY-CONSTITUTION.md`, which is preserved as historical normative evidence) 2. `CLAIMS.md` 3. `GOVERNANCE.md` 4. `spec/CHANGE-CONTROL.md` diff --git a/OAM-ROLE-RECONCILIATION.md b/OAM-ROLE-RECONCILIATION.md new file mode 100644 index 0000000..7220772 --- /dev/null +++ b/OAM-ROLE-RECONCILIATION.md @@ -0,0 +1,192 @@ + + + +# OAM Role Reconciliation + +**Work order:** CAT-ALIGN-001B +**Date:** 2026-09-08 +**Status:** RESOLVED BY OWNER DISPOSITION, 2026-09-08 +**Controlling source:** [THESIS.md](THESIS.md) — Veraxis Category Thesis v1.0 + +## Why this record exists + +CAT-ALIGN-001B requires the controlling thesis to name each Veraxis reference primitive's role. +For OAM it forbids inventing or silently selecting a canonical expansion or role, and requires a +census of currently maintained public definitions first, because public surfaces have used +materially different descriptions over time. + +That census found a genuine conflict. It is recorded here rather than resolved by editorial +preference. + +## Census scope + +Every repository reachable by the executing account under `veraxis-protocol` (14 total) was +searched for `OAM` and `Open Audit Mission` across Markdown, text, JSON, Python, Go and CFF files. + +## Definitions found + +### 1. Institutional Continuity Infrastructure — README reference table + +- **Repository / file:** `veraxis-protocol/institutional-continuity` — `README.md`, line 171 +- **Blob:** `fc28bdc9db7f044344f4034a4cce70dd9ceb1416` (at `origin/main` + `549430974b9511261e997f8f67febb7ad99b503a`) +- **Expansion:** Open Audit Mission +- **Exact role stated:** + + > | **OAM — Open Audit Mission** | Standing/examination workflow where appropriate. | + +- **Reading:** a downstream, examination-side role. Standing to examine, and the workflow by which + examination happens. It constrains nothing at runtime. + +### 2. Open Institutional Compiler — admission contract + +- **Repository / file:** `veraxis-protocol/Institutional-Compiler` — + `design/admission-boundary-001/ADMISSION-CONTRACT-v0.1.md`, line 112 +- **Blob:** `1128bdbcc42dc47a355551fa230bab6f7420accc` (at `main` + `c3d986229e2d7874a30a318981f5045e3f793236`); last touched by commit + `fbb90d950f378e16928426e429e29ba2fbe650e8` +- **Expansion:** none given +- **Exact role stated:** + + > A later OCE/runtime stage may compute consequences; OAM/ZTL may constrain operational + > authority; and VEIP may record or verify execution consequences. None is designed or + > implemented here. + +- **Reading:** an authority-constraining role. Constraining operational authority is a control-side + function that acts on what a runtime may do, not an examination of what it did. + +### 3. AuthContract — component mention + +- **Repository / file:** `veraxis-protocol/AuthContract` — `README.md`, line 1101 +- **Blob:** `22e8cb43684ae6631f68e20b61146d14cbcc6b5d` (at `origin/main` + `6c677aec730bff79dfc60a88d1721564000ad111`) +- **Exact role stated:** + + > The Veraxis research stack uses components including OIC, ZTL, OAM, VEIP, and AEP to reason + > about parts of this chain. + +- **Reading:** names OAM as a stack component but assigns it no role. Not in conflict; not a + definition either. + +### 4. Institutional Compiler Review Ledger — operational usage + +- **Repository:** `veraxis-protocol/Institutional-Compiler-Review-Ledger` at + `713381f866798a950e02cf19c3270e145af94369` +- **Files:** `owner-decisions/AUTHORIZE-M1-S2-LEDGER-NATIVE-EXECUTION-001.md`, + `owner-decisions/AUTHORIZE-M1-CLOSURE-ENV-001-CONDITIONAL-R1-001.md`, and evidence transcripts + under `stage-m1-closure/evidence/r1/` +- **Exact usage:** `OAM` appears only as an identifier prefix on audit gates and reports — + `OAM-GATE-SAR-05-CDC-PROFILE-AUDIT-003`, `OAM-GATE-SAR-05-CDC-AUDIT-INDEX.json`, + `OAM-CDC-PROFILE-CORRECTION-…-INDEPENDENT-REVIEW-RETURN-001.md` +- **Reading:** operationally an audit and gate-governance function. Consistent with the + examination reading of definition 1, but expressed as gates that a candidate must satisfy, which + is closer to a control than to a post-hoc examination. No prose role statement exists. + +### 5. The repository named for it + +- **Repository:** `veraxis-protocol/Open-Audit-Mission` +- **State:** **empty — no commits.** The clone reported `your current branch 'main' does not have + any commits yet`. +- **Consequence:** the repository that carries the name holds no definition at all. The canonical + home for an OAM definition is currently vacant. + +## Do the definitions conflict? + +**Yes.** Definitions 1 and 2 are materially different, not two phrasings of one role: + +| | ICI README | OIC admission contract | +|---|---|---| +| Function | standing and examination workflow | constrains operational authority | +| Position | downstream of consequence | upstream of, or at, runtime | +| Effect on a runtime decision | none | binding | +| ICI plane | evidentiary authority | causal / institutional authority | + +`spec/AUTHORITY-PLANES.md` in this repository holds that collapsing institutional, causal and +evidentiary authority produces false assurance. The two OAM definitions sit on opposite sides of +exactly that distinction, so this cannot be reconciled by choosing softer wording. + +Definition 4's gate usage does not settle it. Audit gates that a candidate must pass read as +constraining, which leans toward definition 2, while the naming and the audit vocabulary lean +toward definition 1. + +## Owner disposition — 2026-09-08, AUTHORIZED + +The owner adopted the examination-side reading, with explicit exclusions. + +> **OAM = Open Audit Mission.** OAM is the examination and audit-authority workflow within +> Open Institutional Computation. OAM governs the bounded process by which an entitled +> human/institutional examiner may inspect continuity evidence, evaluate findings, record +> disposition, preserve replay/correction history, and determine whether the result of an +> examination is fit for later institutional reliance. + +OAM does **not**: originate institutional authority; interpret or compile governing policy; +perform institutional admission; determine the logical warrant owned by ZTL; authorize an exact +runtime action; replace VEIP's execution-integrity boundary; or collapse evidentiary authority +into causal/runtime authority. + +OAM may affect whether an institution subsequently relies on, accepts, corrects, escalates or +rejects an examined result. That is examination and evidentiary authority, not runtime causal +authority — which keeps OAM on one side of the authority-planes non-collapse rule rather than +straddling it. + +### Consequent actions + +| Open question from the census | Owner disposition | +|---|---| +| Which role does OAM carry? | The examination-side role, with the exclusions above. | +| Should `Open-Audit-Mission` be the canonical home? | **Yes.** A minimal bounded README only; no invented implementation status. | +| Do the `OAM-GATE-*` identifiers imply a control function? | **No.** They are audit/examination gates over evidence, review, disposition, release or institutional reliance. They are not evidence that OAM owns runtime authorization. Historical identifiers are not renamed. | +| Who corrects the OIC admission contract, and under what record? | A successor or erratum in `Institutional-Compiler`, under that repository's own governance. The preregistered predecessor is not edited in place. | + +The corrected statement, per the owner: + +> ZTL may constrain what is logically warranted for downstream reliance. VEIP/runtime +> enforcement may constrain whether an exact action may execute. OAM governs examination/audit +> disposition and may constrain later institutional reliance on examined results; OAM does not +> authorize exact runtime execution. + +## Recommended canonical role + +**Recommendation: definition 1 — the examination-side role — with an explicit exclusion.** This was the recommendation put to the owner, and it was adopted; the authoritative wording is the owner disposition above. + +Wording as originally proposed: + +> **OAM — Open Audit Mission.** Standing and examination workflow: who is entitled to examine a +> continuity claim, and the process by which that examination is conducted and recorded. OAM does +> not constrain operational authority at runtime and does not originate institutional authority. + +Reasons: + +1. It matches the only public surface that actually defines OAM with an expansion and a role. +2. It keeps OAM on the evidentiary-authority plane, preserving the non-collapse rule. +3. It leaves the constraint function to ZTL, which the same OIC sentence already pairs with OAM + and which the ICI README independently defines as bounded logical warrant. +4. It is the narrower claim. If OAM later needs a control-side role, adding one is a deliberate + expansion with its own authorization, whereas starting broad and retreating is a claim + reduction on a published surface. + +**Consequence if adopted:** the OIC admission contract's sentence becomes inaccurate as to OAM. +That file is preregistered design evidence carrying its own claim ceiling and +`NOT SELF-ADJUDICATED` marker. It should not be edited in place to agree with a later decision; +correcting it is a successor-record operation in that repository, under that repository's +governance. + +## Is owner authorization required? + +**Yes.** This is a semantic conflict between two published Veraxis surfaces, one of which is +preregistered design evidence in a claim-controlled repository. CAT-ALIGN-001B forbids resolving +it by editorial preference, and THESIS.md's own change-control rule requires an owner-authorized +successor for any change to a component's architectural relationship. + +Until the owner decides, THESIS.md states only that OAM's exact canonical role is subject to this +record, and no component README may infer an OAM role from the thesis. + +## Open questions for the owner + +1. Adopt the recommended examination-side role, adopt the control-side role, or define OAM as + carrying both under explicitly separated planes? +2. Should `veraxis-protocol/Open-Audit-Mission` become the canonical home for the definition, given + that it is currently empty? +3. Does the `OAM-GATE-*` identifier family in the review ledger reflect an intended control + function, or is it naming convention only? +4. Who corrects the OIC admission contract's OAM sentence, and under which successor record? diff --git a/README.md b/README.md index fc28bdc..b38cefc 100644 --- a/README.md +++ b/README.md @@ -8,11 +8,29 @@ > **SOURCE → ADMITTED MEANING → WARRANTED CONTROL → RUNTIME AUTHORITY → EXACT ACTION → CONSEQUENCE → INDEPENDENT OBSERVATION → RECONCILIATION → EXAMINATION** [![Status: PRE-1.0](https://img.shields.io/badge/status-PRE--1.0-orange)](STATUS.md) -[![Category: ICI](https://img.shields.io/badge/category-Institutional%20Continuity%20Infrastructure-blue)](spec/CATEGORY-CONSTITUTION.md) +[![Field: Open Institutional Computation](https://img.shields.io/badge/field-Open%20Institutional%20Computation-5b2d8e)](THESIS.md) +[![Architecture: ICI](https://img.shields.io/badge/architecture-Institutional%20Continuity%20Infrastructure-blue)](spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md) [![Benchmark: ICTS](https://img.shields.io/badge/benchmark-ICTS-informational)](benchmark/README.md) [![Research paper DOI: 10.5281/zenodo.22135315](https://zenodo.org/badge/DOI/10.5281/zenodo.22135315.svg)](https://doi.org/10.5281/zenodo.22135315) [![Docs: CC BY 4.0](https://img.shields.io/badge/docs-CC%20BY%204.0-lightgrey)](LICENSE.md) +## Where this sits + +**Field / category:** Open Institutional Computation +**Architecture:** Institutional Continuity Infrastructure (ICI) + +ICI is a reference end-to-end continuity architecture within the broader field of Open Institutional Computation. It is not a competing parent category. + +The field's central missing computation is **institutional authority computation**: the governed transformation through which human institutional sources, authorized interpretation and admission, currentness, scope, delegation, conditions, exceptions and required evidence become machine-operational authority/control state. ICI is the architecture for preserving and independently examining that transformation end to end; it is not the transformation itself. + +Within that field, [OIC](https://github.com/veraxis-protocol/Institutional-Compiler) is the upstream institutional-compilation component, [VEIP](https://github.com/veraxis-protocol/veip-spec) is the downstream execution-integrity boundary, enforcement runtimes are consumers, and an Evidence Pack is a downstream artifact rather than a source of authority. + +**Canonical category thesis:** [THESIS.md](THESIS.md) — the owner-authorized controlling source for Veraxis category positioning. + +The current normative statement of the ICI architecture is [spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md](spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md). It supersedes `spec/CATEGORY-CONSTITUTION.md` on the category relationship only; the canonical chain, joins, non-collapse rules, falsifiability and implementation neutrality are carried forward unchanged, and the predecessor is preserved as historical normative evidence. This repository keeps its own scope, status, invariants and claim ceilings; only its architectural role is inherited. + +--- + **Agent authorization is necessary. It is not sufficient.** A machine can be correctly authorized to execute the wrong institutional meaning. diff --git a/THESIS.md b/THESIS.md new file mode 100644 index 0000000..7a03fbb --- /dev/null +++ b/THESIS.md @@ -0,0 +1,362 @@ + + + +# Veraxis Category Thesis + +STATUS: OWNER-AUTHORIZED CONTROLLING CATEGORY SOURCE +VERSION: 1.0 +OWNER: Arkadiy Miteiko +DATE: 2026-09-08 + +APPLIES TO: +- all Veraxis public repositories; +- README category positioning; +- veraxis.io; +- decks and pre-reads; +- partner and customer engagements; +- public technical explanations; +- proposals and commercialization materials; +- AI-generated summaries derived from Veraxis public artifacts. + +## Precedence + +This document governs category positioning and component relationships. +Component repositories may define their own implementation scope, status, +interfaces, and claim ceilings, but may not redefine their architectural +role in the Veraxis category hierarchy without an owner-authorized successor +to this document. + +## 1. Category definition + +The category is **Open Institutional Computation**. + +Open Institutional Computation is the open, falsifiable study and engineering of +how institutional authority and institutional meaning become computable — how a +human institution's governing sources, its authorized interpreters, and its +admission acts produce machine-operational control state that a runtime may act +on, and how that relationship remains examinable afterward. + +It is a field, not a product. Multiple independent implementations, including +non-Veraxis implementations, may occupy it. + +## 2. Missing-computation definition + +The central missing computation is **institutional authority computation**: + +> the governed transformation through which human institutional sources, +> authorized interpretation/admission, currentness, scope, delegation, +> conditions, exceptions, and required evidence become machine-operational +> authority/control state. + +### The critical distinction + +Permission checking asks: + +> "Does this action satisfy this rule?" + +Institutional authority computation asks: + +> "Why is this the rule entitled to govern this action now?" + +The first question is well served by existing policy engines, authorization +services, and enforcement runtimes. The second question is the one that is not +reliably machine-operational today, and it is the question this category is +organized around. + +## 3. Canonical architecture + +``` +HUMAN GOVERNING SOURCES + ↓ +AUTHORIZED INTERPRETATION / ADMISSION + ↓ +OIC + ↓ +MACHINE-OPERATIONAL AUTHORITY / CONTROL STATE + ↓ +VEIP + ↓ +CAGE / OPA / AGENT RUNTIME + ↓ +EXACT CONSEQUENTIAL ACTION + ↓ +EVIDENCE PACK / AEP + ↓ +CONSEQUENCE / OBSERVATION / EXAMINATION +``` + +Position in this architecture is an architectural statement. It is not a +statement that any component currently performs its role in production. See +section 10. + +## 4. Exact OIC role + +**OIC — Open Institutional Compiler.** + +OIC is the upstream institutional-compilation component. + +Its architectural role is: + +> governing source +> → source-grounded candidate meaning +> → explicit uncertainty +> → authorized institutional admission +> → machine-operational control/authority state. + +OIC does **not** create institutional authority. Institutional authority remains +externally constituted, and admission remains an institutional act performed by +parties with the required standing. Machine extraction may propose meaning; +authorized institutional admission is required before proposed meaning becomes +admitted meaning. + +OIC makes admitted institutional meaning computationally usable. It operates +upstream of VEIP and upstream of runtime enforcement. + +## 5. Exact VEIP role + +**VEIP — Veraxis Execution Integrity Protocol.** + +VEIP is the execution-integrity and interoperability protocol downstream of +institutional authority/control formation. + +VEIP consumes externally established or admitted machine-operational authority +or control state, and binds and preserves that state across the boundary to an +exact proposed action, a runtime disposition, an execution transition, and +verifiable evidence. + +VEIP does **not**: + +- interpret governing documents as institutional truth; +- perform institutional admission; +- originate institutional authority. + +A VEIP deployment that is functioning perfectly still says nothing about whether +the upstream institutional meaning it is preserving was correctly interpreted or +validly admitted. That is the upstream problem, and it belongs to OIC. + +## 6. Exact Evidence Pack / AEP role + +An **Authorization Evidence Pack / Evidence Pack** is an **artifact**. + +It records or proves the relationship among: + +- authority/control state; +- exact action; +- runtime decision; +- execution/evidence state. + +An Evidence Pack is **not** the category. It is **not** VEIP itself. It does +**not** create institutional authority. A cryptographically valid Evidence Pack +establishes only the bounded cryptographic and structural integrity properties +actually verified under the applicable schema/profile. It does not by itself +establish truth, completeness, institutional validity, correct upstream +interpretation, consequence occurrence, or observation coverage. + +Normative schema terminology is preserved as published. Where a specification +says "Evidence Pack," it is not renamed to "AEP" for messaging purposes. +Terminology in a normative specification changes only through that +specification's own governance process. + +## 7. Enforcement / runtime role + +**CAGE, OPA, and other agent runtimes are enforcement consumers.** + +They evaluate or enforce machine-operational control state. They are not the +origin of institutional authority. An enforcement decision inherits whatever +institutional warrant its inputs carry; it does not manufacture warrant that the +inputs lack. + +## 8. ICI role + +**ICI — Institutional Continuity Infrastructure.** + +ICI is the end-to-end continuity architecture and examination framework under the +broader field of Open Institutional Computation. It defines the canonical chain, +the joins, the invariants, and the ICTS conformance methodology by which a +continuity claim can be falsified. + +ICI is a reference end-to-end continuity architecture within the broader field of +Open Institutional Computation. It is not a competing parent category. + +## 8a. Reference primitive roles + +This section exists so that fixing the category does not silently redefine or erase +components that already exist. Each entry states an architectural role only. None is +a capability, maturity or readiness claim; each component's own repository governs +what may be claimed about it. + +**OIC — Open Institutional Compiler.** +Upstream institutional compilation: source-grounded candidate meaning → explicit +uncertainty → authorized institutional admission → machine-operational control state. + +**ZTL — Zero-Trust Logic.** +Bounded logical warrant: tests what conclusions follow from admitted grounds without +silently converting absence, uncertainty, provenance, or external authority into facts +that have not been established. + +**VEIP — Veraxis Execution Integrity Protocol.** +Execution-integrity/interoperability boundary: binds and preserves applicable +machine-operational authority/control and warrant state to exact proposed actions and +runtime transitions, producing verifiable downstream evidence. + +**OAM — Open Audit Mission.** +Examination and audit-authority workflow: governs entitled examination of continuity +evidence, human/institutional disposition, replay, correction, and whether examined +results are fit for later institutional reliance. + +OAM does not originate institutional authority and does not authorize exact runtime +execution. + +Canonicalized by owner disposition on 2026-09-08, resolving the conflict recorded in +[OAM-ROLE-RECONCILIATION.md](OAM-ROLE-RECONCILIATION.md). The canonical public home for +the definition is `veraxis-protocol/Open-Audit-Mission`. + +**ICI — Institutional Continuity Infrastructure.** +End-to-end continuity architecture and falsification/examination framework within Open +Institutional Computation. + +**AuthContract.** +Developer-facing reference artifact and control boundary where applicable. It is not a +parent category and does not create institutional authority. + +**Runtime Admissibility.** +Research and runtime-currentness primitive where applicable. It is not a parent +category. + +Primitives named on other Veraxis surfaces but without a reachable repository in the +censused set — including VICCP, RegSpine and CAGE — are deliberately not assigned roles +here. Assigning one from an unreachable surface would be the same defect this record +exists to prevent. + +## 9. Terminology distinctions + +### Abbreviation rule: "OIC" is the compiler, never the field + +The field is **Open Institutional Computation**. The component is the **Open Institutional +Compiler**. Only the component is abbreviated. + +- Write the field out in full. Never abbreviate it to "OIC". +- "OIC", unqualified, always means the Open Institutional Compiler. +- On first use in any public artifact, expand the component: "OIC — Open Institutional Compiler". + +This rule exists because independent evaluators reading Veraxis surfaces in isolation reported the +two senses collapsing — one recorded "Two senses appear", another that "the acronym is also used +for the category name". A reader who cannot tell the field from the component cannot place the +component within it, which defeats the purpose of fixing the category at all. + +| Term | Meaning | +|---|---| +| **Open Institutional Computation** | The field. Never abbreviated. | +| **OIC** | Always the Open Institutional Compiler, the upstream component. Never the field. | +| **Policy** | Human/institutional statement of intended governance. | +| **Institutional authority** | Externally constituted entitlement by which a person, office, source, rule, delegation, or institutional process may govern a consequence. | +| **Admission** | Institutional act accepting bounded meaning/control for a stated scope/use. | +| **Permission** | Bounded authorization for a specific action under applicable authority/control. | +| **Warrant** | Machine-verifiable basis for relying on a particular authority/control state. | +| **VEIP** | Execution-integrity protocol preserving/binding relevant state across runtime boundaries. | +| **Evidence Pack / AEP** | Evidence artifact describing/proving a bounded authorization/execution relationship. | +| **Enforcement** | Runtime evaluation or action based on machine-operational control state. | +| **Institutional Continuity** | End-to-end preservation/examination of the warranted chain from source through consequence and later reliance/examination. | + +## 10. Claim-control rule + +**Role statements are architecture statements, not implementation claims.** + +This document places components in a hierarchy. It does not assert that any +component has achieved, demonstrated, or validated the capability implied by its +position. + +This document preserves, and does not override: + +- repository-specific `STATUS`; +- `CLAIMS.md`; +- capability matrices; +- benchmark status; +- validation scope; +- research claim ceilings. + +Where a repository's own documentation establishes a narrower demonstrated +scope, that narrower scope governs what may be claimed about that repository. + +No sentence in this document may be read as asserting that OIC currently +performs production institutional compilation or production runtime +authorization. Its repository does not establish that, and this document does +not extend it. Where implementation status requires it, external wording uses +"is developing" rather than "produces." + +## 11. External engagement rule + +Every new external technical or commercial pre-read SHOULD identify: + +``` +GOVERNING CATEGORY THESIS: +Veraxis Category Thesis v1.0 + +``` + +External explanations should establish the following sequence before discussion +centers on implementation artifacts: + +1. **Missing computation:** institutional authority is not reliably + machine-operational from human governing sources. +2. **OIC:** governed source-to-admitted-control transformation. +3. **VEIP:** runtime execution-integrity/interoperability boundary. +4. **Evidence Pack/AEP:** downstream evidence artifact. + +If an engagement focuses on AEP security, cryptography, signing, replay, tamper +resistance, registry, or retention, those discussions are valid but must not +redefine AEP as the source of institutional authority. + +### Canonical external summary + +> Veraxis is making institutional authority computable for machines. +> OIC produces machine-operational institutional control state. +> VEIP binds and preserves that state into runtime. +> Enforcement systems act on it. +> Evidence Packs record what happened. + +Use wording carefully where implementation status requires "is developing" +rather than "produces." + +## 12. Perception test + +The category-perception gate for this thesis is maintained at +[governance/CATEGORY-PERCEPTION-GATE.md](governance/CATEGORY-PERCEPTION-GATE.md). + +Given only the artifact being evaluated, a reader — human or AI — should be able +to answer: + +1. What category is Veraxis proposing? +2. What is the primary missing computation? +3. What does OIC do? +4. What does VEIP do? +5. What is an Evidence Pack/AEP? +6. Does VEIP originate institutional authority? +7. Does an Evidence Pack prove its own upstream institutional validity merely by + being cryptographically valid? + +An artifact that leads a competent reader to answer "Veraxis is primarily an +Evidence Pack company" has failed this test regardless of its technical +accuracy. + +## 13. Change-control rule + +Any future public change that materially changes: + +- OIC ↔ institutional authority +- OIC ↔ admission +- VEIP ↔ authority/control state +- VEIP ↔ Evidence Pack/AEP +- Evidence Pack ↔ evidence +- ICI ↔ category +- CAGE/runtime ↔ enforcement + +requires an owner-authorized successor to this document **first**. + +Component READMEs inherit the category hierarchy. They do not independently +redefine it. + +This document does not itself change any normative specification. Where a +normative specification in any repository states a category or role differently, +that specification is changed only through its own governance process, and this +document does not silently override it. diff --git a/WEBSITE-CATEGORY-PATCH.md b/WEBSITE-CATEGORY-PATCH.md new file mode 100644 index 0000000..00f1990 --- /dev/null +++ b/WEBSITE-CATEGORY-PATCH.md @@ -0,0 +1,115 @@ + + + +# veraxis.io Category Patch — to be applied later + +**Work order:** CAT-ALIGN-001, updated under CAT-ALIGN-001B +**Controlling source:** [THESIS.md](THESIS.md) — Veraxis Category Thesis v1.0 +**Status:** NOT APPLIED. The website has **not** been modified. This is an exact patch +specification for later application by someone with access to the site source. + +## Provenance of the current copy recorded here + +- **Reviewed surface:** `https://veraxis.io` — homepage; the category/hero statement, the "why is + this the rule" framing, the OIC card, and the VEIP card. +- **Date reviewed:** 2026-09-08. +- **Read by:** the owner, independently, and supplied to this record in work order CAT-ALIGN-001B. + **Not read by the executing session.** A fetch of `https://veraxis.io` from this environment was + refused by the network egress policy (`EGRESS_BLOCKED`) and was not retried or routed around, so + the copy below is quoted as supplied rather than transcribed from the live page. Anyone applying + this patch should re-verify the exact current strings against the live page first. + +## Website source: still unresolved + +All 14 repositories reachable by the executing account were searched for `index.html`, any +`.html`, `CNAME`, `_config.yml`, `netlify.toml`, `vercel.json`, `next.config.*`, `astro.config.*` +and GitHub Pages deployment workflows. **Zero matches.** The site is deployed from outside that +set — a hosted site builder, a private repository, or an account this session cannot reach. + +Identifying the source remains the blocking dependency for the website portion of this work. + +## What is already correct — KEEP + +The homepage does **not** need a wholesale rewrite. The category framing is already right, and +these elements should be preserved as they stand: + +| Element | Current live copy | Disposition | +|---|---|---| +| Category / hero | "The next $1T AI market is Open Institutional Computation." | **KEEP.** Names the field correctly and first. | +| Missing-computation framing | "Policy engines can execute a rule. The harder question is: why is this the rule?" | **KEEP.** This is the permission-checking vs institutional-authority-computation distinction, stated well. | +| OIC card | source anchoring → candidate meaning → ambiguity → institutional admission → machine-operational control → lineage | **KEEP.** Correct upstream sequence, correctly attributed to OIC. | +| Evidence limitation statement | the site's explicit statement that execution evidence alone does not establish consequence, observation coverage, or later examinability | **KEEP. Do not weaken or remove.** This is one of the strongest claim-control statements on any Veraxis surface. | + +The earlier version of this document proposed inserting a "missing computation is authority" +block above the first evidence-heavy explanation. That proposal is **withdrawn**: the live page +already leads with the category and the authority question. Adding it would duplicate correct copy. + +## The one demonstrated defect — the VEIP card + +The VEIP card currently foregrounds a primary label materially equivalent to: + +> **Portable execution evidence** + +and asks whether another system can verify what happened. + +That makes the evidence artifact the headline for the component whose actual job is the +authority-to-execution binding. It is the specific surface that lets a reader — or an AI +summarizing the page — conclude that VEIP *is* the Evidence Pack. That is the perception failure +this work order exists to correct, and it is the only homepage element that requires a change. + +### Proposed replacement card + +**Current primary label:** "Portable execution evidence" + +**Proposed primary role:** "Execution integrity" (or "Authority-to-execution integrity") + +**Proposed card, exact:** + +``` +### Veraxis Execution Integrity Protocol +Execution integrity + +Can a runtime bind the exact action it is about to take to the current +machine-operational authority and warrant state it is entitled to rely on? + +VEIP + +Authority/control state → exact action → runtime disposition → +execution-integrity binding → verifiable evidence. + +Evidence Packs are downstream artifacts. They do not create the institutional +authority they record. +``` + +Evidence stays on the card — it is genuinely part of what VEIP produces — but it moves to the end +of the sequence, where it belongs, instead of serving as the component's name. + +## Claim constraints on the applied copy + +These bind whoever applies the patch. + +- **Do not claim current functionality beyond repository evidence.** OIC's repository establishes a + bounded reference implementation; production compilation and runtime authorization remain + unestablished and its broader production semantic gate remains BLOCKED. Where implementation + status requires it, use "is developing" rather than "produces". +- All eight preregistered OIC-Bench rows remain `TARGET — NOT MEASURED`, and the comparative target + remains `PROVISIONAL TARGET — NOT MEASURED — NOT CALIBRATED`. The site must not report a + benchmark result. +- Do not assert that Google Cloud, Backbase, Fujitsu, or any other party has adopted OIC or VEIP. +- Do not present an Evidence Pack / AEP as the category, as VEIP itself, or as a source of + institutional authority. +- Do not assert that CAGE, OPA, any runtime, or OIC autonomously creates institutional authority. +- Preserve the exact component names: Open Institutional Compiler (OIC), Veraxis Execution + Integrity Protocol (VEIP). +- A cryptographically valid Evidence Pack establishes only the bounded cryptographic and + structural integrity properties actually verified under the applicable schema/profile. It does + not by itself establish truth, completeness, institutional validity, correct upstream + interpretation, consequence occurrence, or observation coverage. + +## Acceptance + +Once applied, run the seven-question gate in +[governance/CATEGORY-PERCEPTION-GATE.md](governance/CATEGORY-PERCEPTION-GATE.md) against the live +page as the sole artifact, and record the result with the page URL and retrieval date. The page +passes only if a reader given nothing but that page answers "Open Institutional Computation" to +question 1 and "no" to questions 6 and 7. diff --git a/governance/CATEGORY-PERCEPTION-GATE.md b/governance/CATEGORY-PERCEPTION-GATE.md new file mode 100644 index 0000000..0e7f37e --- /dev/null +++ b/governance/CATEGORY-PERCEPTION-GATE.md @@ -0,0 +1,107 @@ + + + +# Category Perception Gate + +**Controlling source:** [THESIS.md](../THESIS.md) — Veraxis Category Thesis v1.0 + +This gate exists because category perception has failed in observed practice. +External readers, including AI systems asked to summarize Veraxis public +artifacts, have centered their analysis on Evidence Packs and evidence +infrastructure rather than on the upstream institutional-authority computation +that gives those artifacts meaning. + +The gate is a **manual, reproducible evaluation**. It is not an automated +AI-dependent CI requirement, and it must not be made one without owner +authorization. + +## How to run the gate + +1. Select one artifact: a repository README, a deck, a pre-read, a landing page, + or an AI-generated summary derived from Veraxis public material. +2. Give a competent reader — or an AI system — **only that artifact**. Do not + supply THESIS.md, and do not supply context from other Veraxis surfaces. +3. Ask the seven evaluation questions below. +4. Compare each answer against PASS semantics. +5. Record the result, the artifact identity (repo, path, commit SHA or URL and + retrieval date), and any FAIL indicator observed. + +An artifact passes only if every answer is materially equivalent to its PASS +semantics. A single FAIL indicator fails the artifact. + +## Evaluation questions + +Given ONLY the artifact being evaluated: + +1. What category is Veraxis proposing? +2. What is the primary missing computation? +3. What does OIC do? +4. What does VEIP do? +5. What is an Evidence Pack/AEP? +6. Does VEIP originate institutional authority? +7. Does an Evidence Pack prove its own upstream institutional validity merely by + being cryptographically valid? + +## PASS semantics + +| # | Required answer | +|---|---| +| 1 | Open Institutional Computation. | +| 2 | Institutional authority / admitted institutional meaning becoming machine-operational. | +| 3 | Upstream source-to-admitted-control institutional compilation. | +| 4 | Downstream execution-integrity / binding / interoperability. | +| 5 | Evidence artifact, not category or authority source. | +| 6 | No. | +| 7 | No. | + +## FAIL indicators + +An answer materially equivalent to any of the following fails the artifact: + +- Veraxis is primarily an Evidence Pack company. +- VEIP is itself an Authorization Evidence Pack. +- AEP is the core category. +- VEIP autonomously creates institutional authority. +- A signature makes institutional meaning valid. +- CAGE/OPA/runtime originates institutional authority. + +## Optional deterministic lexical check + +The following is a **supporting** check only. Passing it does not establish +category perception, and failing it does not by itself fail an artifact. It +exists to catch the most common mechanical omission: a public surface that +positions a component without naming the field it sits in. + +For a repository README that carries category positioning, check that it: + +- contains the exact string `Open Institutional Computation`; +- contains a link to the canonical `THESIS.md`; +- where it names Evidence Packs or AEP, does not describe them as the category; +- where it describes a downstream component, states what must already exist + upstream. + +This check is lexical. It is not a substitute for the seven-question gate. + +## Recording results + +A gate result should record: + +- artifact identity (repository and path with commit SHA, or URL with retrieval + date); +- evaluator (human or named AI system and version); +- the seven answers as given, not as paraphrased into compliance; +- PASS or FAIL; +- each FAIL indicator observed; +- the remediation, if any, and the resulting artifact identity. + +Answers must be recorded as actually given. Rewriting an evaluator's answer to +match PASS semantics destroys the only signal this gate produces. + +## Claim boundary + +This gate measures how an artifact is *perceived*. It measures nothing about +implementation maturity, validation status, or demonstrated capability. An +artifact may pass this gate while its repository's `STATUS`, `CLAIMS.md`, and +capability documentation establish a narrow demonstrated scope. Those documents +govern what may be claimed; this gate governs only whether the category is +legible. diff --git a/governance/CATEGORY-PERCEPTION-RESULTS-2026-09-08.md b/governance/CATEGORY-PERCEPTION-RESULTS-2026-09-08.md new file mode 100644 index 0000000..5474558 --- /dev/null +++ b/governance/CATEGORY-PERCEPTION-RESULTS-2026-09-08.md @@ -0,0 +1,132 @@ + + + +# Category Perception Results — 2026-09-08 + +**Work order:** CAT-ALIGN-001B section 6 +**Gate:** [governance/CATEGORY-PERCEPTION-GATE.md](CATEGORY-PERCEPTION-GATE.md) +**Controlling source:** [THESIS.md](../THESIS.md) + +## Method + +Ten surfaces, three independent fresh evaluations each: **30 evaluations**. Each evaluator was a +separate cold session given exactly one artifact path and the seven gate questions. Each was +instructed to read that file only, to search nothing, to use no prior knowledge of the +organization, and to say so explicitly where the artifact did not answer a question. + +**Evaluators were never told the expected answers.** They were additionally asked, in their own +words, what they would say the organization's primary business or product is — the question that +actually detects the failure this work order exists to correct. + +Rounds 1 and 2 ran against the surfaces as they stood after CAT-ALIGN-001. Round 3 ran after the +two corrections below, and therefore doubles as post-fix verification. + +## Headline result + +**Zero FAIL indicators across all 30 evaluations.** + +Not one evaluator, on any surface, in any round, identified Veraxis primarily as an Evidence Pack, +receipt, or audit-record company. None described VEIP as an Evidence Pack, treated AEP as the +category, or said that VEIP or a runtime originates institutional authority, or that cryptographic +validity establishes institutional meaning. + +- **Q1 (category):** "Open Institutional Computation" — **30/30**. +- **Q6 (does VEIP originate authority):** "No" wherever the artifact addressed it — no evaluator + ever answered yes. +- **Q7 (does cryptographic validity prove upstream validity):** "No" wherever addressed — no + evaluator ever answered yes. + +## Defects found in rounds 1–2, and fixed + +### 1. The "OIC" abbreviation collided with the field name + +Three evaluators, on three different surfaces, independently reported the abbreviation collapsing +two distinct things. Verbatim: + +- *"Two senses appear. As a category, 'Open Institutional Computation.' As a component, 'OIC — + Open Institutional Compiler'."* (veip-verifier-core, round 1) +- *"the acronym is also used for the category name 'Open Institutional Computation'"* + (runtime-admissibility, round 1) +- *"it is both the category name … and the named upstream reference path"* (veip-sdk, round 1) + +**Fix:** THESIS.md section 9 now carries an explicit abbreviation rule — the field is always +written out and never abbreviated; "OIC" unqualified always means the Open Institutional Compiler. + +**Round 3 verification, THESIS.md, asked directly whether the abbreviation is used ambiguously:** +*"No — Section 9 explicitly establishes an abbreviation rule."* + +### 2. VEIP was undefined on two of its own downstream surfaces + +- veip-registry, round 1: *"VEIP: Never expanded or defined … What VEIP does is not stated."* + Q6 answered *"unstated for VEIP."* +- veip-registry, round 2: *"The README doesn't spell out VEIP's function directly."* +- veip-verifier-core, round 1: *"The README never defines its function directly."* + +**Fix:** both role blocks now expand the acronym and state VEIP's role and its three non-roles. + +**Round 3 verification:** + +- veip-registry: *"VEIP (Veraxis Execution Integrity Protocol) is the execution-integrity and + interoperability boundary that binds already-established machine-operational authority/control + state … does not interpret governing documents, perform institutional admission, or originate + institutional authority."* Q6: *"No."* +- veip-verifier-core: Q4 answered in full; Q6: *"No. Line 15 explicitly states VEIP 'does not + originate institutional authority'."* + +Both defects are closed. + +## Per-surface result + +| Surface | R1 | R2 | R3 | Verdict | +|---|---|---|---|---| +| THESIS.md | PASS | PASS | PASS | **PASS** — strongest surface; all seven answered from the text | +| institutional-continuity README | PASS | PASS | PASS | **PASS** — field/architecture distinction read correctly every time | +| veip-spec README | PASS | PASS | PASS | **PASS** | +| veip-sdk README | PASS | PASS | PASS | **PASS** — Q2 answered as the SDK's own boundary, with the upstream gap correctly flagged | +| veip-verifier-core README | PASS, Q4 weak | PASS, Q4 weak | PASS | **PASS after fix** | +| veip-registry README | PASS, Q4/Q6 weak | PASS, Q4/Q6 weak | PASS | **PASS after fix** | +| Institutional-Compiler README | PASS | PASS | PASS | **PASS** — Evidence Pack/AEP absent by design; OIC is upstream of them | +| AuthContract README | PASS | PASS | PASS | **PASS** | +| runtime-admissibility README | PASS | PASS | PASS | **PASS** — VEIP/Evidence Pack absent by design; see accepted limitation below | +| website proposed copy | PASS | PASS | PASS | **PASS** | + +## Disagreements, preserved + +The gate requires disagreements to be recorded rather than smoothed over. + +1. **What the business *is* — genuine divergence.** On veip-spec, rounds 1 and 2 read a + "standards-and-certification business", noting the spec is given away under CC BY 4.0 while + certification marks are retained under trademark; round 3 read it plainly as "publishing an open + technical specification". Same text, materially different commercial inference. Similar split on + veip-sdk: "a self-declared standards/certification-registry play" (R1) versus "a minimal + reference implementation SDK" (R3). Neither reading is a FAIL indicator, and the surfaces do not + have to resolve it, but the ambiguity is real and is recorded. + +2. **Q2 varies by surface, as expected.** Component READMEs name their own component's problem + rather than the field's missing computation. THESIS.md, the ICI README, the OIC README and the + website copy all name institutional authority computation correctly. Component surfaces are not + expected to restate the field thesis, and this is not scored as a miss. + +3. **An observation several evaluators volunteered.** Multiple independent readers noted that the + surfaces disclaim a great deal and demonstrate comparatively little — "the actual product is the + category itself", "pre-product research and governance scaffolding", "the disclaimers about what + a PASS does not establish are longer than the description of what it does". This is a direct + consequence of the claim ceilings these repositories deliberately enforce, and it is the correct + trade at this stage. It is recorded because it is what a careful outside reader actually takes + away, and the owner should know that. + +## Accepted limitations, not defects + +- **runtime-admissibility README** mentions neither VEIP nor Evidence Packs, in all three rounds. + That is correct for its scope: it is a research repository about the runtime + currentness/admissibility boundary. Adding VEIP vocabulary to make a gate question answerable + would widen the artifact for the test's benefit rather than the reader's. Q4/Q5/Q7 are recorded + as unanswerable there by design. +- **Institutional-Compiler README** does not mention Evidence Pack or AEP. Also correct: OIC sits + upstream of both. + +## Claim boundary + +This gate measures perception. It establishes nothing about implementation maturity, validation +status or demonstrated capability, and no result here changes any repository's `STATUS`, +`CLAIMS.md`, capability matrix or benchmark position. diff --git a/spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md b/spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md new file mode 100644 index 0000000..52fdb2f --- /dev/null +++ b/spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md @@ -0,0 +1,129 @@ + + + +# ICI Architecture Constitution + +**Field / category:** Open Institutional Computation +**Architecture:** Institutional Continuity Infrastructure + +**Status:** PRE-1.0 normative design baseline, v0.2 +**Supersedes:** `spec/CATEGORY-CONSTITUTION.md` (ICI Category Constitution, v0.1) + +## Change record + +Required by [CHANGE-CONTROL.md](CHANGE-CONTROL.md). + +1. **Predecessor identity.** + Path `spec/CATEGORY-CONSTITUTION.md`, blob + `514ad07939635978ba82e69adac2575c5ce88c63`, at commit + `549430974b9511261e997f8f67febb7ad99b503a`. Titled "ICI Category Constitution", + PRE-1.0 normative design baseline. **Preserved, not deleted, not edited in place.** + +2. **Successor identity.** + This document, `spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md`, PRE-1.0 normative design + baseline v0.2, issued under CAT-ALIGN-001B. + +3. **Rationale.** + Open Institutional Computation is the parent field/category. Institutional Continuity + Infrastructure is the reference end-to-end continuity architecture within that field. + The predecessor presented ICI as the category itself, which made ICI read as a competing + parent category on public surfaces and obscured the field the architecture belongs to. + +4. **Exact semantic change.** + **CATEGORY RELATIONSHIP ONLY.** ICI is restated as an architecture within Open + Institutional Computation rather than as the parent category. Nothing else changes. + +5. **Compatibility impact.** + None. No canonical-chain change. The nine-node chain, the joins, the full-continuity + rule, the non-collapse rules, bounded-satisfaction semantics, falsifiability and + implementation neutrality are carried forward unchanged in substance below. + +6. **Benchmark impact.** + None. No change to eligibility, vectors, expected dispositions, schemas, ICTS + methodology or pass conditions. No implementation gains or loses a score. + +7. **Formal-obligation impact.** + None. No proof obligation in `formal/` is added, removed or altered. + +8. **Migration impact.** + Public references to the ICI constitution should point to this successor. The + predecessor remains valid historical normative evidence and remains addressable at its + path and blob. + +9. **Claim-ceiling impact.** + None. Every claim ceiling in `CLAIMS.md` and `STATUS.md` continues to apply unchanged. + This document makes no maturity, production, benchmark, adoption or legal-effect claim, + and broadens none. + +10. **Owner / design-authority approval.** + CAT-ALIGN-001B / Arkadiy Miteiko / 2026-09-08. + +## Position within the field + +Open Institutional Computation is the field concerned with how institutional authority and +institutional meaning become computable: how governing sources, authorized interpretation +and admission produce machine-operational control state that a runtime may act on, and how +that relationship remains examinable afterward. + +ICI is the reference end-to-end continuity architecture within that field. It is not a +competing parent category. It defines the canonical chain, the joins, the invariants and the +conformance methodology by which a continuity claim can be falsified. + +The controlling category source is [THESIS.md](../THESIS.md). + +## Definition + +**Institutional Continuity Infrastructure (ICI) is infrastructure for preserving and independently verifying the continuity of institutional authority and meaning from authoritative source through machine consequence and later examination.** + +## Canonical chain + +> **SOURCE → ADMITTED MEANING → WARRANTED CONTROL → RUNTIME AUTHORITY → EXACT ACTION → CONSEQUENCE → INDEPENDENT OBSERVATION → RECONCILIATION → EXAMINATION** + +## Full-continuity rule + +A claim of **full Institutional Continuity** requires every mandatory canonical join J1–J8 to be established under the applicable pinned profile and evidence requirements. + +A profile may bound **how** a required join is established. It may not redefine full ICI by removing a required join. + +`NOT_APPLICABLE` does not satisfy a required join for a full-ICI claim. + +`ESTABLISHED_BOUNDED` may satisfy a join only where the exact pinned profile explicitly permits bounded satisfaction for that exact join and states the bound. + +## Non-collapse rules + +1. source existence ≠ source authority; +2. represented/extracted meaning ≠ admitted meaning; +3. logical warrant ≠ external truth; +4. control eligibility ≠ execution authorization; +5. identity ≠ institutional standing; +6. authorization ≠ execution; +7. execution ≠ consequence; +8. consequence receipt ≠ independent observation; +9. record integrity ≠ population completeness; +10. causal authority ≠ evidentiary authority; +11. correction ≠ historical erasure; +12. vendor availability ≠ historical verifiability. + +## Falsifiability + +If any required material edge cannot be established, the system must not claim full Institutional Continuity. It may claim the narrower property actually established. + +## Implementation neutrality + +ICI is larger than any one Veraxis product stack. + +Independent systems may implement the same interfaces and joins. Conformance is determined by pinned evidence and benchmark rules, not vendor identity. + +## Note on the successor identifier + +`spec/` filenames in this repository are otherwise unversioned, and `VERSIONING.md` carries +versions through tags (`ici/vMAJOR.MINOR.PATCH`) and the component-state table in `STATUS.md`, +where the ICI category model is recorded as a v0.1 design baseline. + +This successor nonetheless carries `-v0.2` in its filename because `CHANGE-CONTROL.md` requires +the predecessor to be preserved rather than overwritten, so predecessor and successor must +coexist under distinct paths. An unversioned second constitution would leave two similarly +named normative documents with no filename-level indication of which supersedes which. The +version increment follows `VERSIONING.md`'s MINOR semantics: a compatible normative change +during PRE-1.0, with a change-control record, and no incompatible semantic, eligibility or +join-boundary change.