+
+
+
+ Candor Report · Verified against source
+ What this thingactually does.
+
+ The PI Platform is a ~77K-line Python "deterministic semantic execution kernel": it takes a natural-language security goal, routes it to one (or a chain) of deterministic pattern-matching micro-agents — overwhelmingly Solidity / Web3 smart-contract scanners — runs each through safety shields and a triplicate "consensus" gate, and records every step in append-only SQLite ledgers. Wrapped around that core: a FastAPI console, a Next.js UI, a layered governance / verification stack, and a genuinely fast Rust port. This report maps what is real, what is scaffolding, and where the two get confused.
+ Think of it as an automated security-review assembly line. You hand it a request in plain English ("audit this smart contract"), and it picks the right specialist checkers, runs them, double-checks the result, and writes everything down in a tamper-proof log. There's a control-panel website on top and a faster engine written in a second language underneath. This report is the honest version: what works, what's half-built, and where the labels promise more than the code delivers.
+
+
+ 19 subsystems audited
+ 213 capabilities scored
+ ~296 micro-agents
+ ~1,200 Python tests
+ 38 agents · adversarially cross-checked
+
+
+
+
+
+ 01 Maturity at a glance
+ The honest distribution
+
+ Every capability was read at the source level and rated on a five-step maturity scale, then a second adversarial pass tried to refute each "production" / "functional" claim. The bar below is the verified result across all 213 capabilities.
+ We looked at every feature in the code and graded it on a five-step scale from "rock solid" to "broken." Then a second reviewer tried to prove the first one wrong. The bar below is what survived that double-check — across all 213 features.
+
+
+
+
28
+
105
+
46
+
22
+
12
+
+ Production real, tested, used — 13%
+ Functional runs & does the thing — 49%
+ Partial happy-path only — 22%
+ Stub canned / not wired — 10%
+ Broken cannot run — 6%
+
+
+
+
62%
Production + Functional
+
~51
SyntaxError source files
+
203
Agents wired & import-clean
+
42
Functional-but-orphaned agents
+
+
10 / 19
Subsystems with genuine determinism (was 1/19 — Track A fixed 9)
+
+
+
+
+ 02 The throughline finding
+
+
Cross-cutting pattern · confirmed empirically in 11+ subsystems
+
Determinism theater
+
+ ✓ RESOLVED — TRACK A
+ 9 subsystems re-hashed content-addressed (wall-clock/uuid excluded, kept as metadata) · ~25 hash sites · reproducibility regression gates added · 647 tests green, 0 residual wall-clock in any hash (independently verified).
+
+
+ The platform's headline promise is determinism — the same input always produces the same output, provable by a SHA-256 hash. Nearly every subsystem brands itself "deterministic" and computes such a hash as proof. But those very hashes bake in datetime.now() and uuid4(), so they change on every run. The one component literally named DeterministicClock just returns wall-clock time — and it's the one wired into the live event fabric. The Rust core is the only subsystem where determinism is real, reproduced, and proven — and it documents this exact anti-pattern as a finding.
+ The whole system is sold on one big promise: "ask the same question twice, get the exact same answer." It even prints a fingerprint to prove the answers match. The catch: that fingerprint secretly includes the current time and a random number, so it's different every single time — which means the proof proves nothing. The part actually named "Deterministic Clock" just reports the wall-clock time. The only piece that genuinely keeps the promise is the faster Rust engine — which, to its credit, openly flags this very problem.
+
+
+
pi_event_fabric ✓"DeterministicEventBus" event hashes derived from wall-clock → fixed: content-addressed, genesis hole closed, 5 gates
+
pi_agent_chain ✓state_hash changed every run (utcnow + random trace_id) → fixed: reproducible across processes
+
pi_interoperability_layer ✓DeterministicClock fed wall-clock into live hashes → fixed: 7 identity hashes content-addressed; clock now metadata-only
+
pi_semantic_diff / radius / validator ✓report_hash / policy_hash used uuid4 + now() → fixed: content-derived, unsorted-set ordering sorted
+
pi_console · connector_fabric · extension_governor ✓report/receipt/manifest hashes uuid- or timestamp-salted → fixed
+
rust-core ✓was already genuine — canonical JSON byte-matches CPython; clock injectable; reproducibility independently verified
+
+
+
+
+
+ 03 What it's built on
+ The capability pillars
+
+ Stripping away the branding, the platform stands on six load-bearing pillars. Their maturity varies sharply.
+ Underneath the marketing, six things are doing the real work. Some are solid; some are mostly an idea with a label on it.
+
+
+
+
+
+
+ 04 Where it is genuinely strong
+ Real, verified strengths
+
+ These survived the adversarial re-check — independently reproduced from the source, not taken on the docstring's word.
+ These are the parts that held up when a second reviewer actively tried to debunk them. They're the real assets.
+
+
+
+
+
+
+ 05 Where it is weak
+ Real weaknesses, ranked
+
+ Severity reflects impact on the platform's stated value proposition and on anyone who trusts its output. High items undermine a headline claim or a security guarantee.
+ Ranked by how much they hurt. High means a core promise or a safety guarantee isn't actually delivered.
+
+
+
+
+
+
+ 06 The honest centerpiece
+ Claims × reality
+
+ The recurring failure mode here is a confident name attached to thinner code. Left: what the name / docstring asserts. Right: what the code actually does, verified.
+ The pattern that comes up again and again: an impressive name over a much smaller reality. Left is what it's called. Right is what it actually does.
+
+
+
The label claims…
…the code actually
+
+
+
+
+ 07 Subsystem by subsystem
+ The full matrix
+
+ All 19 audited subsystems. The mini-bar shows each one's own maturity distribution. Click any row for its purpose, standout strength & weakness, and the verified verdict.
+ Every part of the system, one row each. The little colored bar shows how healthy that part is. Click a row to expand the details.
+
+
+
+
+
+
+ 08 Where to point next
+ Highest-leverage moves
+
+ Grounded in the findings above — each closes a specific verified gap. Ordered by leverage: how much truth-value or capability it buys per unit of effort. These are starting points for the conversation, not a committed roadmap.
+ Ideas for what to do next, each one fixing a specific problem we found. Ordered by bang-for-buck. These are conversation starters, not a locked plan.
+
+
+
+
+
+
+
+
How this report was produced
+
+ Nineteen subsystem auditors read the real source in parallel and rated every capability; nineteen adversarial reality-checkers then tried to refute each "production"/"functional" claim and each strength, reading the cited file:line evidence and reproducing behavior where possible (38 agents, ~4M tokens, ~1,100 tool calls). Where a verifier marked a claim "overstated," this report follows the reality, not the original claim. Findings were synthesized against the live tree at HEAD.
+ Nineteen reviewers read the code in parallel and graded every feature. Then nineteen skeptics tried to disprove each grade by re-reading the exact lines and re-running the behavior. When the skeptic won, this report sides with the skeptic. So what you're reading is the conservative, double-checked version.
+
+
This is an honest internal assessment — it deliberately surfaces gaps the marketing names hide. Numbers are exact where reproduced; a few counts (e.g. 51 vs 57 broken files) vary by counting method and are noted as ranges.
+
+
+
+