a69de813cb
Two-pass hardening of the #690 demo so no epistemic state is proposer-mintable: Pass 1 (sealed corpus, from the reconciliation pass): - evidence items are references only (evidence_id + content_sha256) resolved against a committed content-addressed corpus (evidence_corpus.json) - support derived from committed subject/predicate match; independence from distinct provenance_root values; proposer support/independence labels are rejected by the closed schema - evidence-strength taxonomy (substrate-capability vs interface-contract) in PUBLIC-DEMO-ROADMAP / DEMO-PACKAGING-CHECKLIST; position-paper refinements Pass 2 (entailment-decided inference, closes a live false-status hazard): - the merged inferred leg required only that premise IDs resolve — a claim with no support citing one unrelated record as a premise was assigned 'inferred' (empirically confirmed). inferred is now decided by generate.proof_chain.entail (sound+complete ROBDD) over resolved corpus premises, cross-checked against the independent truth-table oracle (evals.deductive_logic.oracle, no shared code); proof keys + oracle verdict in the trace; disagreement => defensive refusal; refutation => contradicted - committed adversarial scenario unrelated-premise-still-undetermined proves the attack now lands on undetermined - corpus seal (corpus_sha256) pinned into every evaluated trace; scope refusals no longer consult the corpus; corpus cache hands out copies; claim subject/predicate constrained to atom-compatible snake_case - .gitignore: private packet dir, agent worktrees, tooling artifacts Validation: 30 demo tests; 96 across all three demo suites; 7/7 scenarios double-run byte-identical; 61 architectural invariants green.
235 lines
8.1 KiB
Markdown
235 lines
8.1 KiB
Markdown
# Public Demo Roadmap
|
|
|
|
This document tracks public, evidence-oriented CORE demos. It intentionally excludes private outreach strategy, named-company planning, fundraising material, and executive packet work.
|
|
|
|
## Public boundary
|
|
|
|
Public repository docs may describe:
|
|
|
|
- implemented demos;
|
|
- proposed demos;
|
|
- deterministic test requirements;
|
|
- trace artifacts;
|
|
- honesty ledgers;
|
|
- public-safe architecture boundaries.
|
|
|
|
Public repository docs must not include:
|
|
|
|
- named-company outreach strategy;
|
|
- named-person contact plans;
|
|
- sponsorship or runway asks;
|
|
- private packet planning;
|
|
- company-specific red-team personas;
|
|
- current-facts dossiers for outreach.
|
|
|
|
## Evidence strength
|
|
|
|
Public demos must distinguish the strength of the evidence they provide.
|
|
|
|
**Substrate-capability demos** route the proposal through a real CORE operator,
|
|
runtime path, sealed eval lane, or independently checked proof surface. These demos
|
|
may support capability claims, within their stated envelope.
|
|
|
|
**Interface-contract demos** prove the typed boundary: closed schema, fail-closed
|
|
validation, proposer-held status ignored, inert outputs, deterministic traces, and
|
|
no side effects. These demos are useful, but they must not be described as proving
|
|
deep CORE reasoning capability by themselves.
|
|
|
|
This distinction is load-bearing. A demo that only checks strings, booleans, or
|
|
schema shape may prove an authority boundary; it does not prove that the geometric
|
|
or deductive substrate made a non-trivial decision.
|
|
|
|
## Demonstrated
|
|
|
|
### Hybrid Verification Demo (#687 — authority over claims)
|
|
|
|
Status: merged (PR #687).
|
|
|
|
Evidence class: substrate-capability demo.
|
|
|
|
Purpose: demonstrate a bounded proposer-to-substrate verification path with typed outcomes. A model-style proposer submits a claim; the substrate, not the proposer, decides the typed outcome.
|
|
|
|
Hard finding recorded by this demo: agreement between reasoning paths is not reliable safety. Multiple paths can agree and still be wrong. Authority must live at the typed boundary, not merely in multiple model outputs.
|
|
|
|
Public outcome vocabulary:
|
|
|
|
- `verified`
|
|
- `refused`
|
|
- `ask`
|
|
- `invalid`
|
|
|
|
Public safety boundary:
|
|
|
|
- no model API;
|
|
- no network;
|
|
- no external side effects;
|
|
- deterministic trace artifacts;
|
|
- honesty ledger included.
|
|
|
|
### Tool Authority Demo (#688 — authority over proposed tool actions)
|
|
|
|
Status: merged (PR #688, merge commit `c55f7dfb`).
|
|
|
|
Evidence class: interface-contract demo.
|
|
|
|
Purpose: demonstrate that a model-style proposer may submit a typed action proposal, while CORE alone may authorize, ask, refuse, or invalidate. The authorized output is an inert `licensed_action` artifact only; no external side effect executes and the proposer holds no execution authority.
|
|
|
|
Evidence caveat: this demo proves the digital-action boundary contract. Its local
|
|
authority evaluator is deliberately small, so it must not be described as proving
|
|
general tool-safety reasoning or production MCP capability. Its value is that the
|
|
proposer cannot self-authorize, inject a license, supply a trusted trace hash, or
|
|
cause side effects.
|
|
|
|
Public outcome vocabulary:
|
|
|
|
- `authorized`
|
|
- `ask`
|
|
- `refused`
|
|
- `invalid`
|
|
|
|
Public safety boundary:
|
|
|
|
- no real tool execution;
|
|
- no real email sending;
|
|
- no shell execution;
|
|
- no network;
|
|
- inert `licensed_action` artifact only;
|
|
- MCP-shaped, not production MCP.
|
|
|
|
### Epistemic Truth-State Demo (#690 — authority over state assignment)
|
|
|
|
Status: merged (PR #690); hardened in this reconciliation pass to use sealed
|
|
evidence references and an entailment-decided inference leg.
|
|
|
|
Evidence class: local epistemic-state authority demo; the `inferred` leg is a
|
|
substrate-capability decision (it routes through the proof-chain entailment
|
|
engine with an independent-oracle cross-check).
|
|
|
|
Purpose: show that a model-style proposer can submit a claim, sealed evidence
|
|
references, and `proposed_state`, while CORE emits the canonical typed state and
|
|
deterministic trace. The proposer controls neither the assigned state nor the
|
|
trace.
|
|
|
|
Public outcome vocabulary:
|
|
|
|
- `verified`;
|
|
- `evidenced`;
|
|
- `inferred`;
|
|
- `contradicted`;
|
|
- `undetermined`;
|
|
- `scope_boundary`;
|
|
- `invalid`.
|
|
|
|
Evidence caveat: the evidence corpus is still local fixture evidence, not live
|
|
vault retrieval or arbitrary web evidence. The proposer supplies evidence
|
|
references only; CORE resolves them by committed content hash and computes support
|
|
and independence from sealed corpus records. `inferred` is assigned only when the
|
|
cited premises propositionally entail the claim's atom under the sound-and-complete
|
|
ROBDD entailment engine, cross-checked against the independent truth-table oracle;
|
|
citing records that merely exist yields `undetermined` (the committed
|
|
`unrelated-premise-still-undetermined` scenario exercises that attack). The demo
|
|
must not be described as production epistemic evaluation across arbitrary evidence
|
|
sources.
|
|
|
|
### Proof-Carrying Coherence Promotion Demo (#696 — vault-owned certified promotion)
|
|
|
|
Status: merged (PR #696).
|
|
|
|
Evidence class: substrate-capability demo within a local deterministic envelope.
|
|
|
|
Purpose: demonstrate deterministic knowledge-admission authority by
|
|
replay-verified proof and vault-owned promotion. A model-style proposer can attach
|
|
status, confidence, proof, certificate, and trace-hash garbage, but CORE fresh-reads
|
|
store state, recomputes the proof under the pinned deductive engine, replay-verifies
|
|
the certificate, and promotes or refuses only through
|
|
`VaultStore.apply_certified_promotion`.
|
|
|
|
Public outcome vocabulary:
|
|
|
|
- `promoted`;
|
|
- `refused`;
|
|
- `invalid`.
|
|
|
|
Evidence caveat: this proves proof-carrying `SPECULATIVE -> COHERENT` promotion
|
|
only for curator-certified readings over already-`COHERENT` premises in a
|
|
fixture-driven local store arena. It does not prove runtime integration,
|
|
open-world autonomous learning, arbitrary evidence ingestion, or normative
|
|
clearance.
|
|
|
|
## Proposed
|
|
|
|
Recommended order of next public evidence:
|
|
|
|
1. Standalone Deductive Entailment Authority Demo (formal entailment showcase);
|
|
2. Embodied Authority Simulation Demo (simulation-only);
|
|
3. SaaS / On-Prem Boundary Demo.
|
|
|
|
Merged evidence establishes four authority boundaries: authority over claims
|
|
(#687), proposed tool actions (#688), epistemic state assignment (#690), and
|
|
vault-owned proof-carrying promotion (#696). The next public target should isolate
|
|
formal entailment itself as a standalone showcase: a proposer supplies premises,
|
|
conclusion, and claimed verdict; CORE decides through the existing deductive/proof
|
|
surface and emits replayable proof evidence.
|
|
|
|
### Standalone Deductive Entailment Authority Demo
|
|
|
|
Status: proposed.
|
|
|
|
Purpose: demonstrate a non-trivial authority boundary over formal entailment. The
|
|
proposer submits premises, a conclusion, and a claimed verdict. CORE decides via
|
|
the existing proof-chain / deductive-logic substrate, with trace evidence that can
|
|
be checked against the independent truth-table oracle discipline already used by
|
|
the deductive lane.
|
|
|
|
Required outcomes:
|
|
|
|
- `entailed`;
|
|
- `refuted`;
|
|
- `unknown`;
|
|
- `refused`;
|
|
- `invalid`.
|
|
|
|
Required proof obligations:
|
|
|
|
- proposer verdict ignored;
|
|
- malformed or out-of-regime logic refused;
|
|
- inconsistent premises refused rather than vacuously proving everything;
|
|
- at least one scenario where the proposer is wrong and CORE's verdict differs;
|
|
- deterministic trace includes canonical proof keys or certificate evidence;
|
|
- no shared-code oracle is presented as independent evidence.
|
|
|
|
### Embodied Authority Simulation Demo
|
|
|
|
Status: proposed, simulation-only.
|
|
|
|
Purpose: demonstrate an authority-boundary pattern for model-proposed simulated transitions.
|
|
|
|
Public safety boundary:
|
|
|
|
- no real robot;
|
|
- no real actuator;
|
|
- no vehicle-control claim;
|
|
- no production robotics claim;
|
|
- no certified functional-safety claim;
|
|
- simulation-only fixtures.
|
|
|
|
### SaaS / On-Prem Boundary Demo
|
|
|
|
Status: proposed.
|
|
|
|
Purpose: demonstrate a public-safe split between coordination metadata and local authority decisions.
|
|
|
|
No claim is made here that a production SaaS or on-prem deployment exists.
|
|
|
|
## Packaging rule
|
|
|
|
Each public demo should include:
|
|
|
|
- README;
|
|
- fixtures;
|
|
- expected outputs;
|
|
- deterministic runner;
|
|
- tests;
|
|
- honesty ledger;
|
|
- "what this proves";
|
|
- "what this does not prove."
|