The receipt boundary: a first outside product wires into DCS Verify

Third entry in the weekly series. The honest summary first: by commit count this was a slow week on the DCS core. Several maintenance windows passed with zero new commits on the main surfaces, and what did move was either a static landing page or boundary plumbing. So rather than dress up a big launch, this post is about the one piece of work that matters more than its size suggests — the seam where something outside DCS started feeding into DCS Verify.

For most of this company's life, DCS Verify has verified our own things: our agent runs, our sites, our receipts. The milestone worth recording is that an external product — one we build but run as a separate venture — is now the first outside consumer wired to emit DCS Verify receipts. It routes a user session through a receipt-emit path in the gateway, which lands a verifiable receipt in DCS storage. That's the boundary we've been building toward: verification as something other products plug into, not just something we run for ourselves.

What moved

1 · A receipt-emit route at the boundary

The wiring lives in the main gateway as a dedicated receipt-emit route. It takes a session from the outside product and turns it into a DCS Verify receipt — the same receipt shape the rest of the platform uses — then forwards it to the storage backend where receipts are persisted and anchored. The important design choice is that the outside product doesn't get to invent its own receipt format; it conforms to ours, or nothing lands. This is the second consecutive week the core has carried code written specifically to serve this boundary, which is the first sign that an integration is a real dependency rather than a demo.

2 · The bug-fixes that prove it's real

Here's the part I find more convincing than any announcement. Two follow-up commits this week fixed the same class of error: the storage layer was rejecting writes with a Postgres 22P02 — "invalid text representation" — because the outside product's session_id and then its tenant_id were arriving as plain strings where the schema expects UUIDs. The fix coerces both to UUIDs before the storage POST. You don't hit a 22P02 on a feature that was never exercised; you hit it the moment real identifiers actually travel the full path. The errors are, paradoxically, the evidence the seam is live in code.

3 · Where the receipts land

On the far side of the route is the DCS storage backend, which carries a per-receipt anchoring design so each receipt can resolve through to an on-chain anchor. I want to be careful here, because anchoring is exactly the kind of claim that's easy to overstate: the anchoring and its compliance checks are committed in code and rerun internally by the integrator, but not independently re-verified on-chain from the outside this week. So the architecture is in place and the route writes into it — but "every receipt has a confirmed anchor you can check" is not a claim I'm making today.

The smaller moves

Two other things touched the public surfaces this week, and both deserve precise labels rather than cheerleading.

First, both marketing sites — dcsai.ai and dcslabs.ai — committed a new pilot-v1 landing page that had previously sat untracked in each repo. It's now in version control and pushed. I'll flag the obvious temptation directly: the commit message says "Gate 1 soak passed," and that phrase is a label on a static page, not proof that a soak test ran. Both repos' build-version files are unchanged, so the page is committed but its deploy isn't confirmed from the outside. When a real soak clears, it will get its own honest entry here — not a commit message standing in for one.

Second, the same honesty rule showed up on the outside product itself. Its early marketplace surface exposes a public stats endpoint, and right now that endpoint returns honest zeros — no waitlist entries, no inflated counts, just the real state. It's the same principle the analytics dashboard runs on: a true zero beats a flattering guess. That the boundary product ships with that reflex is, to me, the most reassuring detail of the week.

An integration you can see failing in the logs is further along than a feature that's only ever been described. The errors are the proof the wire is connected.

What is not done yet (and we want you to know it)

The cadence holds

The standing rule is unchanged: R+2 and R+3 are operational prototypes, R+4 is a research prototype, the trusted-setup ceremony is a v0.1, and federation remains a reference design and simulations — not a live multi-node network. None of that moved this week, and I'm not going to imply it did. What moved was a seam: the first time an outside product became a real dependency on DCS Verify, proven by the small, specific bugs that only a live wire produces. Some weeks the headline is a launch. This week the headline is a 22P02 we were glad to fix.

— Deepak