every claim has a live verify linkpre-revenue · stated plainlyno asserted valuation

Technical due diligence — verify the asset.

This page is for someone evaluating the codebase, not a buyer being sold to. We don't assert a dollar valuation — that's speculative and not ours to certify. Instead, every architectural claim below links to the running system so you can confirm it's real and decide for yourself. The limitations are stated as plainly as the strengths.

The real pillars — each verifiable now

1 · Agent-native operations over MCP + REST

A protocol-compliant Model Context Protocol server exposing 46 governed, signed tools (plus a REST surface and an OAuth 2.1 + Dynamic Client Registration layer). Not a chatbot bolted onto a CRUD app — the platform is built to be run by agents.

2 · Three deterministic governance kernels (isomorphic, zero-dep)

A trilogy of Apache-2.0 policy engines whose exact logic runs server-side and in your browser: the Constitution gates the action (priority caps, forbidden terms, objective alignment, quiet hours, daily caps); the injection screen guards untrusted input (OWASP LLM01); the ABAC authz kernel gates access to a specific resource by attributes (deny-overrides, fails closed). Each is live and runnable right now.

3 · A cryptographic identity + audit stack

A W3C DID method with a spec-compliant resolver, portable Verifiable Credentials, and a real signed-Merkle inclusion-proof chain: the signed decision log commits to an ECDSA-signed SHA-256 Merkle root, and any record yields an inclusion proof you verify against the public JWKS without trusting our database. Scoped honestly: retain a signed checkpoint, then tamper with a record, and the root recomputed from the log no longer matches the checkpoint you held — third-party-detectable tampering relative to a root you previously saved. (The endpoint recomputes and re-signs the current log each read; it's not a full append-only transparency log with consistency proofs — that's the documented next step.)

4 · The governed control loop + human approval ledger

A rewindable loop — simulate → execute → verify → undo — where a low-confidence or gated action is paused and pushed to a human approval queue (HTTP 202 + an approval id), then resumes on decision. Plus forecasting, a signed decision log, and a fleet roster. The map shows all of it, every node a live endpoint.

5 · Protocol intelligence — AI model routing + MCP contract validation

Two more zero-dep, isomorphic kernels completing the "above-API" layer. The route kernel deterministically selects the best AI provider from a BYOK config given task constraints (type, payload size, latency, cost, privacy) — hard filters first (health, capability, token capacity, privacy level), then weighted scoring — and returns a ranked provider list with rationale and a signed attestation. The MCP schema validator is runtime Protobuf-style field-contract checking for MCP tool/call arguments: type, required, enum, bounds, format, nullable, additionalProperties — per-field typed errors, signed attestation bound to the (args, schema) digest. Both Apache-2.0, both runnable in your browser right now.

Evaluated and explicitly declined

Every "above-API" suggestion was triaged. These were reviewed and not built — with the reasons stated plainly so you can judge the call yourself.

gRPC / HTTP3 / Protocol Buffers transport

Cloudflare Pages Functions are HTTP endpoints — not gRPC servers. The binary-serialization / sub-millisecond latency claim is perf theater for a governance API: the bottleneck is never JSON parsing, it's database I/O and signing. The genuine IP here is the routing and validation logic, not the wire format.

tRPC end-to-end type safety

tRPC requires a live Node.js server. The EcoCloud app exports as a static SPA (output: 'export' in Next.js). They are architecturally incompatible. The genuine benefit — runtime type safety at the call boundary — is exactly what the MCP schema validator delivers, without the incompatibility.

Cloudflare Durable Objects event mesh

Durable Objects require the Workers billing tier and a different deployment pattern than Pages. The Salesforce event-stream example in the review was illustrative fiction. We are not going to add a billing-tier dependency to demonstrate a pattern that isn't wired to a real integration.

Zero-knowledge proofs for auth

EcoCloud already has real W3C DID-Core resolution, ECDSA P-256 signed Verifiable Credentials, and a Merkle audit chain with inclusion proofs — all verifiable against the published JWKS without trusting our database. ZKPs for web auth require trusted setup ceremonies, are not yet standardized for this use case, and would add a cryptographic claim we cannot truthfully sustain. We won't label ECDSA "a ZKP system."

WebGPU LLM inference in the browser

CSP-incompatible with the existing site security policy, off-thesis (the platform's value is agent governance, not in-browser inference), and would deliver a fake-AI demo that calls a real model and pretends it ran locally. Not built.

Stated plainly — what this is, and isn't

Genuinely here

  • The four pillars above — all running, all linked
  • Every signed artifact verifies against the published JWKS
  • A measured benchmark (~2ms at 500k tasks) with the query plans
  • Live, real, anonymized system counts at /metrics

We won't overstate

  • We don't assert a dollar valuation — that's speculative, not ours to certify
  • "AI Dispatch" is fast deterministic parsing (regex), not on-device ML — we won't call a regex "edge NLP"
  • Pre-revenue: the counts at /metrics are real and small, not vanity numbers
  • No money primitives — EcoCloud carries the proof of agent work, never the funds

The honest case for the codebase isn't a number — it's that the hard parts (deterministic agent governance, a signed audit chain, standards-based agent identity) are built and verifiable, not slideware. Check the links, then form your own view of what that's worth.

// the governed loopsimulateconstitutionexecutesignedverifyES256 · audit-chained