Reframe Open CoT around cognitive reconciliation

docs/philosophy.md

@@ -1,47 +1,39 @@
 # Philosophy
 
-Open-CoT exists to make **governed agent execution** interoperable: a shared, machine-verifiable contract between model output, runtime enforcement, policy, delegation, tools, provenance, and audit.
+Open CoT exists to make the boundary between cognition and capability portable.
 
-We are deliberately opinionated about **where trust lives**. Capability flows through grants, policy, and brokers—not through persuasive text in the model channel. That can feel heavier than ad-hoc agent scripts; the bet is that regulated and multi-vendor environments will prefer **one inspectable contract** over many implicit ones.
+The model-like component is useful because it can interpret, compress, explain, and propose. It is not useful as an authority boundary. Open CoT treats its output as a cognitive artifact: structured, inspectable, and untrusted until a runtime reconciles it against capability, policy, budget, and evidence.
 
 ## Principles
 
-### Typed schemas over ambiguous prose
+### Typed artifacts over ambiguous prose
 
-Every serious boundary—reasoning steps, tool intent, FSM phase, delegation, permission, receipt, audit envelope—is expressed as **JSON Schema** and validated by the harness. Natural language may explain *why* a human approved something; it does not define *whether* a transition is legal.
+Every serious boundary should be expressed as JSON Schema: cognitive artifact, capability snapshot, execution intent, policy material, observation, receipt, and reconciliation result. Natural language can explain context; it cannot grant permission.
 
-### The model is an untrusted proposer
+### Capability snapshots over ambient access
 
-Models suggest plans and capability needs. They **never** authorize themselves. The harness treats model output like any other untrusted input: parse, validate, consult policy, then either advance the FSM or refuse. Obedience to the model is a bug.
+Cognition receives an explicit snapshot of available endpoints. The snapshot binds endpoint names, input shape, risk, approval requirement, and digest. Requests outside that snapshot are invalid.
 
-### Portable harness semantics
+### Execution intent is not execution
 
-The governed FSM and artifact shapes are **model-agnostic**. Any model that can emit structured output (or sit behind an adapter that shapes output) can participate. Portability comes from shared control-plane semantics, not from standardizing hidden chain-of-thought prose.
+An execution intent is a proposal. A runtime must validate shape, snapshot identity, capability digest, arguments, policy, risk, approval, budget, and preconditions before side effects occur.
 
-### Explicit provenance and evidence
+### Policy is separate from validation
 
-Side effects and decisions leave **receipts** and audit-linked records. A completed run should answer: what was requested, what was allowed, what ran, and how integrity was sealed. Silence is not accountability.
+Zod, JSON Schema, or any other validator can prove shape. They cannot prove permission. Policy gates are separate artifacts and should leave their own evidence.
 
-### Permission-aware execution
+### Observations over transcript trust
 
-Tool calls require **explicit authority**—grants with scope and lifetime, or a documented standing authorization cited on the execution receipt. Permission is a runtime object managed by the trust stack, not a vibe inferred from the prompt.
+Endpoint output becomes an observation. Observations are structured runtime records, not loose transcript text. They can carry result data, skipped work, validation failures, policy refusals, and reconciliation errors.
 
-### Delegation as a bounded request
+### Reconciliation over orchestration by text
 
-When more capability is needed, the agent issues a formal **delegation request**. Policy approves, narrows, denies, or escalates. The auth broker issues a narrowed receipt. Delegation is not a model-signed blank check.
+The runtime owns progression. The cognitive step emits an artifact, then yields to the runtime boundary. This keeps retries, crash recovery, endpoint execution, and audit in deterministic code.
 
-### Fail-closed safety
+### Implementation pressure should improve the standard
 
-If validation fails, **deny**. If observation violates policy, **quarantine** and route toward **`fail_safe`** rather than leaking unsafe material back to the model. If budgets exhaust, **stop**. Uncertainty defaults to refusal, not optimism.
+Open Lagrange is a proving ground, not a competing dialect. If it needs a portable structure, Open CoT should gain or refine an RFC/schema. Runtime-specific choices stay local; reusable interfaces belong here.
 
-Designs that “try the tool call and roll back” still owe the same receipts: optimism belongs in the training loss, not in the authorization boundary.
+### Backward compatibility without freezing vocabulary
 
-### Token-aware by design
-
-Structure costs tokens, and tokens cost money and context. The control plane should not burn the model's budget on bureaucracy. Capability manifests (RFC 0049) tell the model what it can do upfront so it does not waste tokens guessing. Compact text serialization keeps the overhead under 200 tokens. Context compilation — summarizing observations, windowing traces, stripping harness metadata — keeps the model focused on the task, not the plumbing. See [`docs/token-efficiency.md`](./token-efficiency.md) for active research on wire formats and small-model strategies.
-
-### Small credible proofs before ambitious claims
-
-The reference harness exists to show that the **contract works**: one end-to-end path that respects the FSM, receipts, and validation. We aim for a narrow, correct slice of the ecosystem—not a declaration that every framework must adopt this stack tomorrow.
-
-If a behavior cannot be expressed in schema and FSM transitions yet, we treat that as a **spec gap** to fix, not as encouragement to bypass the harness with bespoke glue code.
+Earlier RFCs use historical terms from the project’s transitional period. Those documents remain part of the record. New work should prefer cognition, capability, execution intent, observation, policy gate, runtime boundary, and reconciliation terminology.

docs/rfc-discussion-index.json

@@ -308,6 +308,18 @@
       "rfc_path": "rfcs/0051-temporal-semantics-validity-extension.md",
       "discussion_title": "RFC 0051 \u2014 Temporal Semantics & Validity Extension",
       "discussion_url": "https://github.com/supernovae/open-cot/discussions/51"
+    },
+    "0052": {
+      "rfc_title": "Cognitive Artifact & Capability Snapshot",
+      "rfc_path": "rfcs/0052-cognitive-artifact-and-capability-snapshot.md",
+      "discussion_title": "RFC 0052 \u2014 Cognitive Artifact & Capability Snapshot",
+      "discussion_url": "https://github.com/supernovae/open-cot/discussions/52"
+    },
+    "0053": {
+      "rfc_title": "Reconciliation Result & Error Taxonomy",
+      "rfc_path": "rfcs/0053-reconciliation-result.md",
+      "discussion_title": "RFC 0053 \u2014 Reconciliation Result & Error Taxonomy",
+      "discussion_url": "https://github.com/supernovae/open-cot/discussions/53"
     }
   }
 }

docs/rfc-discussions.md

@@ -58,4 +58,5 @@ Canonical discussion threads for all Open CoT RFCs. Use these threads for normat
 | [`RFC 0049`](../rfcs/0049-capability-manifest.md) | Capability Manifest | [Open thread](https://github.com/supernovae/open-cot/discussions/49) |
 | [`RFC 0050`](../rfcs/0050-toon-adapter.md) | TOON Adapter: Token-Oriented Object Notation | [Open thread](https://github.com/supernovae/open-cot/discussions/50) |
 | [`RFC 0051`](../rfcs/0051-temporal-semantics-validity-extension.md) | Temporal Semantics & Validity Extension | [Open thread](https://github.com/supernovae/open-cot/discussions/51) |
-
+| [`RFC 0052`](../rfcs/0052-cognitive-artifact-and-capability-snapshot.md) | Cognitive Artifact & Capability Snapshot | [Open thread](https://github.com/supernovae/open-cot/discussions/52) |
+| [`RFC 0053`](../rfcs/0053-reconciliation-result.md) | Reconciliation Result & Error Taxonomy | [Open thread](https://github.com/supernovae/open-cot/discussions/53) |

rfcs/0052-cognitive-artifact-and-capability-snapshot.md

@@ -0,0 +1,48 @@
+# RFC 0052 — Cognitive Artifact & Capability Snapshot (v0.1)
+
+**Status:** Draft  
+**Author:** Open CoT Community  
+**Created:** 2026-04-27  
+**Target Version:** Schema v0.10
+**Discussion:** https://github.com/supernovae/open-cot/discussions/52
+
+---
+
+## 1. Summary
+
+This RFC defines portable structures for runtimes that wrap non-deterministic
+cognitive functions with deterministic validation and execution boundaries.
+
+The core structure is a **Cognitive Artifact**: a typed proposal emitted by a
+model or model-like system. It is untrusted input. A runtime validates and
+reconciles it against an immutable **Capability Snapshot** before performing
+any side effect.
+
+## 2. Core concepts
+
+- `capability_snapshot`: immutable inventory of endpoints available to the
+  cognitive step.
+- `cognitive_artifact`: typed proposal emitted from the cognitive step.
+- `execution_intent`: requested endpoint execution tied to a snapshot and
+  capability digest.
+- `observation`: structured evidence recorded during reconciliation.
+
+## 3. Normative requirements
+
+- A cognitive artifact MUST NOT be treated as authorization.
+- Every execution intent MUST reference the exact snapshot used for generation.
+- A runtime MUST verify endpoint name, capability name, and capability digest
+  before execution.
+- A runtime MUST validate arguments against the original capability input
+  schema.
+- Reasoning traces are explanatory audit material only. They are not proof,
+  authorization, or trusted state.
+
+## 4. Runtime neutrality
+
+This RFC does not require a specific durable execution engine, MCP transport,
+model provider, or TypeScript implementation. Those are implementation choices.
+
+## 5. Schema
+
+Machine-readable schema: `schemas/rfc-0052-cognitive-artifact.json`.

rfcs/0053-reconciliation-result.md

@@ -0,0 +1,57 @@
+# RFC 0053 — Reconciliation Result & Error Taxonomy (v0.1)
+
+**Status:** Draft  
+**Author:** Open CoT Community  
+**Created:** 2026-04-27  
+**Target Version:** Schema v0.10
+**Discussion:** https://github.com/supernovae/open-cot/discussions/53
+
+---
+
+## 1. Summary
+
+This RFC defines a portable result envelope for runtimes that reconcile typed
+cognitive artifacts against capability snapshots, policy gates, execution
+bounds, endpoint results, and observations.
+
+The result envelope records what executed, what was skipped, what errors were
+observed, and the final reconciliation status.
+
+## 2. Status values
+
+- `completed`
+- `completed_with_errors`
+- `yielded`
+- `requires_approval`
+- `failed`
+
+## 3. Error taxonomy
+
+The portable taxonomy includes:
+
+- `INVALID_ARTIFACT`
+- `SNAPSHOT_MISMATCH`
+- `UNKNOWN_MCP_SERVER`
+- `UNKNOWN_CAPABILITY`
+- `CAPABILITY_DIGEST_MISMATCH`
+- `SCHEMA_VALIDATION_FAILED`
+- `POLICY_DENIED`
+- `APPROVAL_REQUIRED`
+- `PRECONDITION_FAILED`
+- `BUDGET_EXCEEDED`
+- `MCP_EXECUTION_FAILED`
+- `RESULT_VALIDATION_FAILED`
+- `YIELDED`
+
+## 4. Normative requirements
+
+- Shape validation MUST NOT be treated as permission.
+- Permission and policy gates MUST be represented separately from schema
+  validation.
+- Errors SHOULD be recorded as structured observations when possible.
+- A reconciliation result SHOULD preserve enough evidence for replay and audit
+  without requiring endpoint re-execution.
+
+## 5. Schema
+
+Machine-readable schema: `schemas/rfc-0053-reconciliation-result.json`.

schemas/registry.json

@@ -52,6 +52,8 @@
     "execution_receipts_audit_envelopes": "schemas/rfc-0048-execution-receipts-audit-envelopes.json",
     "capability_manifest": "schemas/rfc-0049-capability-manifest.json",
     "toon_adapter": "schemas/rfc-0050-toon-adapter.json",
-    "temporal_semantics": "schemas/rfc-0051-temporal-semantics.json"
+    "temporal_semantics": "schemas/rfc-0051-temporal-semantics.json",
+    "cognitive_artifact": "schemas/rfc-0052-cognitive-artifact.json",
+    "reconciliation_result": "schemas/rfc-0053-reconciliation-result.json"
   }
 }