From e7295e02bf50ad9fb25b1ea343e42ced5cf41442 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 22:04:40 +0000 Subject: [PATCH 1/8] CAT-ALIGN-001: add controlling Veraxis category thesis Establish THESIS.md as the owner-authorized controlling category source for Veraxis public surfaces, and add the manual category-perception gate it references. The category is Open Institutional Computation. The central missing computation is institutional authority computation. OIC is the upstream institutional compilation component; VEIP is the downstream execution-integrity boundary; an Evidence Pack / AEP is a downstream artifact, not the category; enforcement runtimes are consumers, not origins of institutional authority; ICI is a reference end-to-end continuity architecture within the field, not a competing parent category. Documentation only. No runtime, schema, benchmark, claim-ceiling or normative specification change. Role statements are architecture statements; repository STATUS, CLAIMS.md, capability matrices and validation scope continue to govern what may be claimed. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- THESIS.md | 295 +++++++++++++++++++++++++ governance/CATEGORY-PERCEPTION-GATE.md | 107 +++++++++ 2 files changed, 402 insertions(+) create mode 100644 THESIS.md create mode 100644 governance/CATEGORY-PERCEPTION-GATE.md diff --git a/THESIS.md b/THESIS.md new file mode 100644 index 0000000..f59fd9a --- /dev/null +++ b/THESIS.md @@ -0,0 +1,295 @@ + + + +# 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 +proves the integrity of what it records; it does not, by itself, establish that +the upstream institutional authority it references was legitimate, correctly +interpreted, properly admitted, or currently applicable. + +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. + +## 9. Terminology distinctions + +| Term | Meaning | +|---|---| +| **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/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. From 9866e7e158e393c2be116991f970884639a4bc73 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 22:12:38 +0000 Subject: [PATCH 2/8] CAT-ALIGN-001: present ICI as architecture, not parent category The README badge read "Category: ICI", which positions Institutional Continuity Infrastructure as the parent category. Under the controlling category thesis the field is Open Institutional Computation and ICI is a reference end-to-end continuity architecture within it. Replace the category badge with a field badge and an architecture badge, and add a short placement section stating the hierarchy, the field's central missing computation, where OIC and VEIP sit, and that an Evidence Pack is a downstream artifact rather than a source of authority. ICI's full-chain model, nine-node canonical chain, eight joins, invariants, ICTS methodology and claim ceilings are unchanged and unweakened. No normative specification is modified: spec/CATEGORY-CONSTITUTION.md is still titled "ICI Category Constitution" and reconciling that title is a normative change requiring a successor artifact under spec/CHANGE-CONTROL.md. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- README.md | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index fc28bdc..ac9bae0 100644 --- a/README.md +++ b/README.md @@ -8,11 +8,27 @@ > **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/CATEGORY-CONSTITUTION.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. 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. From 70b3dec6d81d3d49cb62fd2f781a4ed5cf2304fd Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 22:22:27 +0000 Subject: [PATCH 3/8] CAT-ALIGN-001: add census, execution report and website patch document Record the full repository census (14 censused, 10 modified, 4 not modified), the per-repository execution record with base and head SHAs and validation results, and the veraxis.io category patch prepared for later application. The website source could not be identified: no reachable repository contains any site source or Pages deployment workflow, and the live site is unreachable from the executing environment under the network egress policy. Rather than fabricate current copy or modify an unrelated repository, the patch document records exact proposed copy, the required architecture sequence, the claim constraints binding whoever applies it, and leaves current copy explicitly blank. Known remaining inconsistencies are recorded rather than silently fixed, including that spec/CATEGORY-CONSTITUTION.md still titles ICI a category. Changing it is a material normative change requiring a successor artifact under spec/CHANGE-CONTROL.md, so it is left for owner decision. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- CAT-ALIGN-001-EXECUTION-REPORT.md | 101 ++++++++++++++++++++++++ CATEGORY-SURFACE-CENSUS.md | 73 ++++++++++++++++++ WEBSITE-CATEGORY-PATCH.md | 123 ++++++++++++++++++++++++++++++ 3 files changed, 297 insertions(+) create mode 100644 CAT-ALIGN-001-EXECUTION-REPORT.md create mode 100644 CATEGORY-SURFACE-CENSUS.md create mode 100644 WEBSITE-CATEGORY-PATCH.md 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..67899ec --- /dev/null +++ b/CATEGORY-SURFACE-CENSUS.md @@ -0,0 +1,73 @@ + + + +# 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. **`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. +5. **`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. +6. **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/WEBSITE-CATEGORY-PATCH.md b/WEBSITE-CATEGORY-PATCH.md new file mode 100644 index 0000000..abd1c6c --- /dev/null +++ b/WEBSITE-CATEGORY-PATCH.md @@ -0,0 +1,123 @@ + + + +# veraxis.io Category Patch — to be applied later + +**Work order:** CAT-ALIGN-001 +**Controlling source:** [THESIS.md](THESIS.md) — Veraxis Category Thesis v1.0 +**Status:** NOT APPLIED. Prepared for later application by someone with access to the site source. + +## Why this document exists instead of a website change + +Work order CAT-ALIGN-001 section IX authorizes a website patch **if and only if** the source that +deploys veraxis.io is available and clearly identified. It is not, for two independent reasons: + +1. **No website source exists in the reachable repository set.** All 14 repositories the executing + account can access were enumerated and searched for `index.html`, any `.html`, `CNAME`, + `_config.yml`, `netlify.toml`, `vercel.json`, `next.config.*`, `astro.config.*`, and for + GitHub Pages deployment workflows (`actions/deploy-pages`, `peaceiris/actions-gh-pages`, + `github-pages`). **Zero matches.** The site is deployed from somewhere outside this set — a + hosted site builder, a private repository, or an account this session cannot reach. +2. **The live site could not be read.** A fetch of `https://veraxis.io` was refused by the network + egress policy (`EGRESS_BLOCKED`). Per the proxy contract that denial was reported, not retried + or routed around. + +Consequently the "current copy" column below **cannot be filled in from evidence** and is left +explicitly empty rather than reconstructed from memory or assumption. The proposed copy is exact +and owner-specified; the current copy must be captured by whoever holds site access before the +diff is applied. + +No unrelated repository was modified as a substitute. + +## What must change, structurally + +The failure being corrected is ordering, not accuracy. The site currently makes evidence and +Authorization Evidence Packs easier to recognize than the upstream institutional-authority +computation that gives them meaning. Two external events demonstrated it: 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. + +So the requirement is a placement requirement: **the authority statement must appear above the +first evidence/AEP-heavy explanation on the page.** Adding the text lower down does not fix it. + +## Block 1 — the missing computation + +**Location:** immediately above the first evidence-, receipt-, or AEP-oriented explanation on the +page. If the hero already carries an evidence-first message, this replaces the hero's leading +explanation and the evidence message moves below it. + +**Current copy:** _(not captured — see above; fill in before applying)_ + +**Proposed copy, exact:** + +> The missing computation is authority. +> +> Enterprise policy is written for humans. Before an agent can act on it, an institution must +> establish what the governing source means, who may admit that meaning, where it applies, whether +> it remains current, and what exact machine action it authorizes. + +## Block 2 — evidence in its place + +**Location:** immediately after Block 1, before or alongside the existing evidence explanation. + +**Current copy:** _(not captured — fill in before applying)_ + +**Proposed copy, exact:** + +> Evidence comes downstream. VEIP preserves and binds machine-operational authority into runtime; +> Evidence Packs record the resulting authorization and execution relationship. They do not create +> the institutional authority being proved. + +## Block 3 — the architecture sequence + +**Location:** wherever the site shows a product or architecture diagram. If none exists, add one. + +The sequence must read, in this order: + +``` +source + → admission + → OIC + → authority/control state + → VEIP + → enforcement/runtime + → exact action + → Evidence Pack + → consequence/examination +``` + +Any existing diagram that begins at the runtime, the gate, or the Evidence Pack is the specific +defect this work order exists to correct. + +## Claim constraints on the applied copy + +These bind whoever applies the patch. They are not optional stylistic guidance. + +- **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). + +## 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. + +## Open item for the owner + +The location of the veraxis.io source is unresolved. Identifying it — repository, hosting platform, +or site builder — is a prerequisite for applying this patch, and is the single blocking dependency +recorded against the website portion of CAT-ALIGN-001. From 2d0a37d5a42f8be5d8b471ac2536db9ec153ffa6 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 22:24:42 +0000 Subject: [PATCH 4/8] CAT-ALIGN-001: record the MAM pre-existing CI toolchain mismatch CI on the MAM alignment PR failed with "cannot compile Go 1.22 code". Root cause is on the base branch, not in the change: go.mod declares go 1.22 while the workflow pins go-version 1.20. The alignment diff there is one Markdown file and touches no Go, no go.mod and no workflow. Recorded as a remaining known inconsistency rather than fixed, since a workflow toolchain bump is not category positioning and is outside this work order's bounded documentation scope. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- CATEGORY-SURFACE-CENSUS.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/CATEGORY-SURFACE-CENSUS.md b/CATEGORY-SURFACE-CENSUS.md index 67899ec..01efa3a 100644 --- a/CATEGORY-SURFACE-CENSUS.md +++ b/CATEGORY-SURFACE-CENSUS.md @@ -62,12 +62,19 @@ These are recorded rather than fixed, each for a stated reason. `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. **`veip-registry` README ends mid-sentence.** The "Relationship to veip-spec" section reads +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. -5. **`white-papers` v1.2 PDF has not been assessed against the thesis.** Binary released artifact; +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. -6. **Component names `VICCP`, `ZTL`, `RegSpine`, `CAGE` and `OAM`** appear in the ICI README's +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. From 4f1da337a30939e5afabc36110803f1c55da7089 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 22:51:17 +0000 Subject: [PATCH 5/8] CAT-ALIGN-001B: harden thesis, add ICI successor, update website patch THESIS.md - Add "Reference primitive roles" so fixing the category does not silently redefine or erase existing components: OIC, ZTL, VEIP, ICI, AuthContract and Runtime Admissibility each get an architectural role, explicitly not a capability claim. VICCP, RegSpine and CAGE are deliberately left unassigned because no reachable repository defines them. - OAM is named without a role, pending OAM-ROLE-RECONCILIATION.md, and no component README may infer one from the thesis. - Narrow the Evidence Pack claim. A cryptographically valid Evidence Pack now establishes only the bounded cryptographic and structural integrity properties actually verified under the applicable schema/profile, and not truth, completeness, institutional validity, correct upstream interpretation, consequence occurrence or observation coverage. OAM-ROLE-RECONCILIATION.md (new) - Census of every reachable OAM definition. Two published surfaces conflict materially: the ICI README defines OAM as a standing/examination workflow, while the OIC admission contract says OAM may constrain operational authority. Those sit on opposite sides of the authority-planes non-collapse rule. Recorded with a recommendation and open questions for owner decision; not resolved by editorial preference. spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md (new) - Normative successor under spec/CHANGE-CONTROL.md carrying all ten required change-record fields. Semantic change is CATEGORY RELATIONSHIP ONLY. - Definition, canonical chain, full-continuity rule, non-collapse rules, falsifiability and implementation neutrality are carried forward byte-identical, verified programmatically against the predecessor blob. - The predecessor is preserved unedited as historical normative evidence. - The filename carries -v0.2 because change control requires predecessor and successor to coexist under distinct paths; the reasoning is recorded in the document. README.md and CONTRIBUTING.md now point at the successor; the predecessor is still named as history. WEBSITE-CATEGORY-PATCH.md - Rewritten against live copy supplied by the owner. The category hero, the "why is this the rule" framing, the OIC card and the evidence-limitation statement are all marked KEEP, and the earlier proposal to insert an authority block is withdrawn as duplicative. - The patch now targets the one demonstrated defect: the VEIP card's "Portable execution evidence" primary label becomes "Execution integrity", with evidence moved downstream in the sequence. - Provenance is explicit: the owner read the site; this session could not, and says so. No runtime, schema, benchmark, claim-ceiling or historical-evidence change. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- CONTRIBUTING.md | 3 +- OAM-ROLE-RECONCILIATION.md | 156 +++++++++++++++++++++ README.md | 6 +- THESIS.md | 55 +++++++- WEBSITE-CATEGORY-PATCH.md | 128 ++++++++--------- spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md | 129 +++++++++++++++++ 6 files changed, 403 insertions(+), 74 deletions(-) create mode 100644 OAM-ROLE-RECONCILIATION.md create mode 100644 spec/ICI-ARCHITECTURE-CONSTITUTION-v0.2.md 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..0771783 --- /dev/null +++ b/OAM-ROLE-RECONCILIATION.md @@ -0,0 +1,156 @@ + + + +# OAM Role Reconciliation + +**Work order:** CAT-ALIGN-001B +**Date:** 2026-09-08 +**Status:** CONFLICT FOUND — OWNER AUTHORIZATION REQUIRED +**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. + +## Recommended canonical role + +**Recommendation: definition 1 — the examination-side role — with an explicit exclusion.** + +Proposed wording, for owner approval and not adopted anywhere yet: + +> **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 ac9bae0..b38cefc 100644 --- a/README.md +++ b/README.md @@ -9,7 +9,7 @@ [![Status: PRE-1.0](https://img.shields.io/badge/status-PRE--1.0-orange)](STATUS.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/CATEGORY-CONSTITUTION.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) @@ -25,7 +25,9 @@ The field's central missing computation is **institutional authority computation 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. This repository keeps its own scope, status, invariants and claim ceilings; only its architectural role is inherited. +**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. --- diff --git a/THESIS.md b/THESIS.md index f59fd9a..eb4fb96 100644 --- a/THESIS.md +++ b/THESIS.md @@ -147,9 +147,10 @@ It records or proves the relationship among: An Evidence Pack is **not** the category. It is **not** VEIP itself. It does **not** create institutional authority. A cryptographically valid Evidence Pack -proves the integrity of what it records; it does not, by itself, establish that -the upstream institutional authority it references was legitimate, correctly -interpreted, properly admitted, or currently applicable. +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. @@ -177,6 +178,54 @@ 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.** +OAM is an existing Veraxis reference primitive whose exact canonical role is subject to +the OAM role-reconciliation record. No component README may infer a new OAM role from +this thesis. + +See [OAM-ROLE-RECONCILIATION.md](OAM-ROLE-RECONCILIATION.md). That census found a +material conflict between two published surfaces — one defining OAM as a standing and +examination workflow, another as constraining operational authority — and it is +recorded for owner decision rather than resolved by editorial preference. + +**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 | Term | Meaning | diff --git a/WEBSITE-CATEGORY-PATCH.md b/WEBSITE-CATEGORY-PATCH.md index abd1c6c..00f1990 100644 --- a/WEBSITE-CATEGORY-PATCH.md +++ b/WEBSITE-CATEGORY-PATCH.md @@ -3,96 +3,90 @@ # veraxis.io Category Patch — to be applied later -**Work order:** CAT-ALIGN-001 +**Work order:** CAT-ALIGN-001, updated under CAT-ALIGN-001B **Controlling source:** [THESIS.md](THESIS.md) — Veraxis Category Thesis v1.0 -**Status:** NOT APPLIED. Prepared for later application by someone with access to the site source. +**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. -## Why this document exists instead of a website change +## Provenance of the current copy recorded here -Work order CAT-ALIGN-001 section IX authorizes a website patch **if and only if** the source that -deploys veraxis.io is available and clearly identified. It is not, for two independent reasons: +- **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. -1. **No website source exists in the reachable repository set.** All 14 repositories the executing - account can access were enumerated and searched for `index.html`, any `.html`, `CNAME`, - `_config.yml`, `netlify.toml`, `vercel.json`, `next.config.*`, `astro.config.*`, and for - GitHub Pages deployment workflows (`actions/deploy-pages`, `peaceiris/actions-gh-pages`, - `github-pages`). **Zero matches.** The site is deployed from somewhere outside this set — a - hosted site builder, a private repository, or an account this session cannot reach. -2. **The live site could not be read.** A fetch of `https://veraxis.io` was refused by the network - egress policy (`EGRESS_BLOCKED`). Per the proxy contract that denial was reported, not retried - or routed around. +## Website source: still unresolved -Consequently the "current copy" column below **cannot be filled in from evidence** and is left -explicitly empty rather than reconstructed from memory or assumption. The proposed copy is exact -and owner-specified; the current copy must be captured by whoever holds site access before the -diff is applied. +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. -No unrelated repository was modified as a substitute. +Identifying the source remains the blocking dependency for the website portion of this work. -## What must change, structurally +## What is already correct — KEEP -The failure being corrected is ordering, not accuracy. The site currently makes evidence and -Authorization Evidence Packs easier to recognize than the upstream institutional-authority -computation that gives them meaning. Two external events demonstrated it: 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. +The homepage does **not** need a wholesale rewrite. The category framing is already right, and +these elements should be preserved as they stand: -So the requirement is a placement requirement: **the authority statement must appear above the -first evidence/AEP-heavy explanation on the page.** Adding the text lower down does not fix it. +| 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. | -## Block 1 — the missing computation +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. -**Location:** immediately above the first evidence-, receipt-, or AEP-oriented explanation on the -page. If the hero already carries an evidence-first message, this replaces the hero's leading -explanation and the evidence message moves below it. +## The one demonstrated defect — the VEIP card -**Current copy:** _(not captured — see above; fill in before applying)_ +The VEIP card currently foregrounds a primary label materially equivalent to: -**Proposed copy, exact:** +> **Portable execution evidence** -> The missing computation is authority. -> -> Enterprise policy is written for humans. Before an agent can act on it, an institution must -> establish what the governing source means, who may admit that meaning, where it applies, whether -> it remains current, and what exact machine action it authorizes. +and asks whether another system can verify what happened. -## Block 2 — evidence in its place +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. -**Location:** immediately after Block 1, before or alongside the existing evidence explanation. +### Proposed replacement card -**Current copy:** _(not captured — fill in before applying)_ +**Current primary label:** "Portable execution evidence" -**Proposed copy, exact:** +**Proposed primary role:** "Execution integrity" (or "Authority-to-execution integrity") -> Evidence comes downstream. VEIP preserves and binds machine-operational authority into runtime; -> Evidence Packs record the resulting authorization and execution relationship. They do not create -> the institutional authority being proved. +**Proposed card, exact:** -## Block 3 — the architecture sequence +``` +### Veraxis Execution Integrity Protocol +Execution integrity -**Location:** wherever the site shows a product or architecture diagram. If none exists, add one. +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? -The sequence must read, in this order: +VEIP -``` -source - → admission - → OIC - → authority/control state - → VEIP - → enforcement/runtime - → exact action - → Evidence Pack - → consequence/examination +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. ``` -Any existing diagram that begins at the runtime, the gate, or the Evidence Pack is the specific -defect this work order exists to correct. +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. They are not optional stylistic guidance. +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 @@ -107,6 +101,10 @@ These bind whoever applies the patch. They are not optional stylistic guidance. - 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 @@ -115,9 +113,3 @@ Once applied, run the seven-question gate in 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. - -## Open item for the owner - -The location of the veraxis.io source is unresolved. Identifying it — repository, hosting platform, -or site builder — is a prerequisite for applying this patch, and is the single blocking dependency -recorded against the website portion of CAT-ALIGN-001. 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. From a759ca25a8c431c3166c541c1320c0873bc54b40 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 22:58:07 +0000 Subject: [PATCH 6/8] CAT-ALIGN-001B: fix the OIC abbreviation collision Three independent evaluators, each reading a single Veraxis surface in isolation, reported the abbreviation 'OIC' collapsing two distinct things: Open Institutional Computation (the field) and Open Institutional Compiler (the component). 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. Add an explicit abbreviation rule to the terminology section: the field is always written out and never abbreviated; OIC unqualified always means the Open Institutional Compiler; the component is expanded on first use. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- THESIS.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/THESIS.md b/THESIS.md index eb4fb96..c37ce5d 100644 --- a/THESIS.md +++ b/THESIS.md @@ -228,8 +228,24 @@ 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. | From 535ec754bb8a7aad3e856e948acd429351719fa5 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 23:00:14 +0000 Subject: [PATCH 7/8] CAT-ALIGN-001B: record 30 category-perception evaluations Ten surfaces, three independent cold evaluations each. Evaluators received one artifact and the seven gate questions, were told nothing about the expected answers, and were asked separately what they thought the business was. Zero FAIL indicators across all 30. Q1 answered 'Open Institutional Computation' 30/30; no evaluator ever answered yes to Q6 or Q7. Records the two defects rounds 1-2 exposed and round 3 confirmed fixed - the OIC abbreviation collision and VEIP being undefined on veip-registry and veip-verifier-core - with verbatim evaluator quotes on both sides of the fix. Preserves disagreements rather than smoothing them: evaluators split on whether the VEIP surfaces read as a standards-and-certification business or simply as a published spec, and several independently observed that the surfaces disclaim much and demonstrate little. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- .../CATEGORY-PERCEPTION-RESULTS-2026-09-08.md | 132 ++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 governance/CATEGORY-PERCEPTION-RESULTS-2026-09-08.md 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. From 3d427eb6dd0205091094e40a730c3edbb8338c91 Mon Sep 17 00:00:00 2001 From: Arkadiy Miteiko Date: Tue, 8 Sep 2026 23:06:15 +0000 Subject: [PATCH 8/8] CAT-ALIGN-001B: canonicalize the OAM role by owner disposition The census recorded a material conflict between two published surfaces: the ICI README defined OAM as a standing/examination workflow, while the OIC admission contract said OAM may constrain operational authority. Those sit on opposite sides of the authority-planes non-collapse rule. The owner adopted the examination-side reading on 2026-09-08. OAM is the examination and audit-authority workflow within Open Institutional Computation: entitled examination of continuity evidence, disposition, replay, correction, and whether an examined result is fit for later institutional reliance. It does not originate institutional authority and does not authorize exact runtime execution. Replace the provisional OAM language in THESIS.md with the canonical role, and record the disposition, the consequent actions and the corrected statement in OAM-ROLE-RECONCILIATION.md. The record keeps the original conflict evidence and the recommendation as put, so the basis of the decision stays legible. Also recorded: OAM-GATE-* identifiers are audit/examination gates, not evidence that OAM owns runtime authorization, and historical identifiers are not renamed. Signed-off-by: Arkadiy Miteiko Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Pkw68qW3iRaeJsiMPBEPvW --- OAM-ROLE-RECONCILIATION.md | 42 +++++++++++++++++++++++++++++++++++--- THESIS.md | 20 ++++++++++-------- 2 files changed, 50 insertions(+), 12 deletions(-) diff --git a/OAM-ROLE-RECONCILIATION.md b/OAM-ROLE-RECONCILIATION.md index 0771783..7220772 100644 --- a/OAM-ROLE-RECONCILIATION.md +++ b/OAM-ROLE-RECONCILIATION.md @@ -5,7 +5,7 @@ **Work order:** CAT-ALIGN-001B **Date:** 2026-09-08 -**Status:** CONFLICT FOUND — OWNER AUTHORIZATION REQUIRED +**Status:** RESOLVED BY OWNER DISPOSITION, 2026-09-08 **Controlling source:** [THESIS.md](THESIS.md) — Veraxis Category Thesis v1.0 ## Why this record exists @@ -109,11 +109,47 @@ Definition 4's gate usage does not settle it. Audit gates that a candidate must 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.** +**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. -Proposed wording, for owner approval and not adopted anywhere yet: +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 diff --git a/THESIS.md b/THESIS.md index c37ce5d..7a03fbb 100644 --- a/THESIS.md +++ b/THESIS.md @@ -199,15 +199,17 @@ 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.** -OAM is an existing Veraxis reference primitive whose exact canonical role is subject to -the OAM role-reconciliation record. No component README may infer a new OAM role from -this thesis. - -See [OAM-ROLE-RECONCILIATION.md](OAM-ROLE-RECONCILIATION.md). That census found a -material conflict between two published surfaces — one defining OAM as a standing and -examination workflow, another as constraining operational authority — and it is -recorded for owner decision rather than resolved by editorial preference. +**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