This packet gives reviewers a compact route through the current inspectable evidence for ProofPath, Compute Witness, and the connected evidence-gate stack.
It is designed around one question:
What can a reviewer inspect or run today?
Evidence Packet v0.1 turns the ecosystem from a set of claims into a small checklist of inspectable artifacts.
High-risk AI/agent actions should not be trusted only because a model produced them, a tool call exists, or credentials are valid.
They should pass through reviewable evidence gates before execution:
proposed action
+ declared intent
+ causal authorization
+ scope
+ reversibility
+ evidence freshness
+ trace continuity
-> ACCEPT / BLOCK / ESCALATE / AUDIT
-> reviewable artifact
This packet is a map of present evidence, not a claim of production maturity.
It separates:
claim
-> current artifact
-> expected result
-> what this supports
-> what it does not prove
A reviewer can inspect the current evidence in this order:
- ProofPath dangerous-action boundary.
- Compute Witness manifest / receipt / verifier path.
- CML causal-validity support layer.
- LTP trace / replay support layer.
- PythiaLabs ALLOW / BLOCK / ESCALATE gate surface.
- LS / Liminal Stack reviewer packet.
- TRC / TPU evidence plan for future larger artifact generation.
Valid credentials are not enough. A high-risk action should be blocked before execution when evidence or approval is missing.
- Demo:
examples/agent-dangerous-action/README.md - Gateway:
crates/proofpath-gateway - Audit log pattern: hash-chained JSONL decisions
- Reviewer summary:
reviewer-summary.md
python3 examples/upstream/demo_server.py
cargo run -p proofpath-gateway
bash examples/agent-dangerous-action/agent_delete_without_approval.sh
bash examples/agent-dangerous-action/agent_delete_with_approval.sh
cat proofpath-audit.jsonlunsafe irreversible delete without approval -> BLOCK
same action with explicit human approval -> ACCEPT
both decisions are written to audit log
- ProofPath can sit before a protected upstream API.
- It can block unsafe irreversible actions before forwarding.
- It can distinguish valid credentials from valid action context.
- It can produce auditable decision records.
- production security;
- production identity management;
- complete prevention of unsafe AI behavior;
- formal verification of all possible action paths.
AI/agent compute results should be packaged as reviewable evidence, not accepted as opaque outputs.
- Grant reviewer path:
COMPUTE_WITNESS_GRANT_REVIEWER_PATH.md - Reviewer quickstart:
examples/compute-witness/README.md - Python conformance fixtures
- Rust verifier adapter and CLI
- Audit-hash verification
- Broken-evidence challenge fixtures
- CI regression check: Compute Witness Rust CLI fixture
Start here:
examples/compute-witness/README.md#reviewer-quickstart
Then inspect:
job manifest
-> receipt
-> audit packet
-> verifier output
-> challenge fixture
valid evidence packet -> verifier accepts
mismatched or broken evidence -> verifier rejects
canonical audit hash remains reproducible
- Compute evidence can be represented as manifests and receipts.
- Broken evidence can be detected through fixtures.
- Rust and Python paths can agree on audit-hash expectations.
- Reviewers can inspect artifacts without trusting a hidden service.
- trusted hardware attestation;
- zkML correctness;
- GPU/TPU execution proof;
- full model-truthfulness guarantees;
- production deployment readiness.
An action can be operationally successful while still being causally invalid.
CML repository:
https://github.com/safal207/Causal-Memory-Layer
Relevant reviewer route:
CML README
-> LS Grant Reviewer Packet 2026
-> ProofPath ecosystem graph
- causal logs;
- valid vs broken causal chains;
- causal violation classes;
- benchmark / showcase outputs;
- why-allowed reasoning.
valid causal lineage -> accepted / explainable
missing or broken causal parent -> violation detected
- ProofPath action boundaries can be connected to causal-validity checks.
- The ecosystem can distinguish execution success from causal authorization.
- Reviewers can inspect why an action was allowed, not only what happened.
- universal causal truth;
- complete policy coverage;
- production authorization integration;
- legal accountability by itself.
Multi-step agent behavior should be traceable and replayable enough to detect drift, missing anchors, or unsupported execution paths.
LTP repository:
https://github.com/safal207/L-THREAD-Liminal-Thread-Secure-Protocol-LTP-
Relevant reviewer route:
LTP README
-> LS Grant Reviewer Packet 2026
-> ProofPath ecosystem graph
- trace / replay examples;
- two-phase semantic inspection;
- anchor validation;
- drift detection;
- conformance fixtures;
- SDK tests.
supported trace with anchors -> proceed / audit
missing or invalid anchor -> reject / block
semantic drift -> audit / block depending on policy
- ProofPath decisions can be placed inside a broader trace/replay model.
- Reviewers can inspect continuity, not only final output.
- Agent behavior can be regression-tested through trace fixtures.
- perfect replay of all real-world environments;
- full semantic equivalence across all models;
- production observability integration;
- final compliance certification.
The same action-boundary pattern can be expressed as deterministic evidence gates for multiple high-risk domains.
PythiaLabs repository:
https://github.com/safal207/pythiaLabs
Relevant reviewer docs:
docs/PYTHIALABS_ONE_PAGE_SUMMARY.md
docs/OTF_REVIEWER_PATH.md
docs/PROOFPATH_CONTINUATION_FOR_REVIEWERS.md
- infrastructure action gate;
- banking-risk action gate;
- Web3 treasury governance gate;
- OTF / internet-freedom reviewer path;
- deterministic stop reasons;
- evidence digests;
- counterfactual decision flips.
sufficient evidence + valid context -> ALLOW
missing evidence / unsafe context -> BLOCK
uncertain or sensitive case -> ESCALATE
- Evidence gates are not limited to one demo.
- The pattern can be mapped to infrastructure, financial, governance, and internet-freedom-sensitive workflows.
- PythiaLabs provides the application-facing surface while ProofPath / Compute Witness provide the current executable evidence continuation.
- production banking integration;
- production cybersecurity protection;
- on-chain enforcement;
- legal or regulatory compliance;
- certified internet-freedom deployment.
The connected repositories form a coherent evidence stack rather than isolated demos.
LS repository:
https://github.com/safal207/LS
Key reviewer document:
docs/GRANT_REVIEWER_PACKET_2026.md
- broad reviewer packet;
- ecosystem route;
- mapping from submitted applications to current executable evidence;
- LS / ProofPath / PythiaLabs / CML / LTP roles.
submitted application surface
-> reviewer packet
-> executable evidence hub
-> support-layer repositories
- Reviewers entering from different grants can find the same evidence core.
- The system has a clear role map.
- Older application names and newer executable work are connected.
- that all repositories are equally mature;
- that every roadmap item is implemented;
- that the stack is already a deployable product.
TRC access should be converted into durable reviewer artifacts, not treated as a standalone credential.
- TRC / TPU evidence plan:
TRC_TPU_EVIDENCE_PLAN.md
- proposed experiment tracks;
- metrics;
- artifact package structure;
- non-claims;
- mapping to Schmidt / Google.org / OTF / OpenAI / NLnet review paths.
TRC compute
-> repeated experiment runs
-> metrics JSON
-> audit logs
-> receipts
-> replay reports
-> reviewer summary
- TRC can become evidence-generation infrastructure.
- The next milestone is measurable and artifact-driven.
- Compute access is tied to reproducible reviewer outputs.
- Google endorsement;
- funding approval;
- production readiness;
- institutional validation;
- solved model safety.
A reviewer-friendly v0.1 evidence checklist should contain:
[ ] ProofPath dangerous action demo produces BLOCK and ACCEPT cases.
[ ] ProofPath audit log records the decisions.
[ ] Compute Witness valid fixture verifies.
[ ] Compute Witness broken fixture fails.
[ ] CML demonstrates at least one causal-validity violation.
[ ] LTP demonstrates at least one trace/replay or anchor-inspection case.
[ ] PythiaLabs demonstrates ALLOW / BLOCK / ESCALATE behavior.
[ ] LS reviewer packet explains the ecosystem route.
[ ] TRC plan explains how larger evidence artifacts will be generated.
Strong interpretation:
The project already has inspectable, runnable, and cross-linked evidence artifacts for action-boundary safety.
Bounded interpretation:
The project is not yet production infrastructure, but it has a coherent evidence path and reproducible demo surface.
Weak interpretation to avoid:
The project claims to solve all AI safety or production security problems.
That is not the claim.
Evidence Packet v0.1 does not claim:
- production deployment;
- institutional endorsement;
- certified security;
- regulatory compliance;
- complete AI alignment;
- trusted execution attestation;
- zkML proof of correctness;
- guaranteed prevention of all unsafe actions;
- finished product maturity;
- that all roadmap components are implemented.
The narrow claim is:
There is now a small, inspectable, cross-repository evidence path for high-risk AI/agent action boundaries.
The next milestone should be an actual generated artifact bundle:
reports/evidence-packet-v0.2.md
reports/action-boundary-metrics.json
reports/compute-witness-conformance.json
reports/cml-causal-validity-results.json
reports/ltp-replay-results.json
reports/pythia-gate-results.json
artifacts/audit-logs/*.jsonl
artifacts/receipts/*.json
artifacts/transcripts/*.md
That would move the stack from:
reviewer routes + demo commands
to:
reviewer routes + generated evidence bundle
Evidence Packet v0.1 is the first compact reviewer checklist.
It does not ask reviewers to believe the whole vision.
It asks them to inspect a small set of artifacts that already show the core pattern:
high-risk action
-> evidence boundary
-> decision
-> audit artifact
-> replay / verification path