Skip to content

Proof-chain control room

A public map of the product loop: choose pain, ship proof, review trust.

This page shows the control plane behind the site. The point is not to list every credential; it is to make the repeatable loop visible enough that a visitor can inspect the artifacts and understand what stays private.

Visitor decision

If you only have 90 seconds, click in this order.

The pass/fail is simple: can three public surfaces show a working loop, recent receipts, and a concrete evaluation rule?

  1. 010:00-0:25

    Walk the compact demo.

    Conclude whether the site has one coherent product loop instead of disconnected portfolio claims.

  2. 020:25-0:55

    Scan recent public receipts.

    Conclude whether recent work leaves inspectable routes, repos, verifier signals, and clear privacy boundaries.

  3. 030:55-1:30

    Open the agent evaluation standard.

    Conclude whether agent trust is judged by artifacts and review burden, not transcript confidence.

Product Owner

Names the pain and the public bet.

Chooses workflow friction worth turning into a small product surface, writes the acceptance bar, and cuts anything that does not strengthen the proof chain.

  • Pain is repeated
  • Artifact can be inspected
  • Private context stays out
Builder

Ships the smallest useful artifact.

Turns the bet into a route, repo, demo, write-up, or scoring harness that survives outside a chat transcript and can be revisited later.

  • Working surface
  • Source or route link
  • Verification command
Reviewer / user-side investor

Decides whether the loop earns more trust.

Reviews the artifact from the user side: did it reduce review burden, create a reusable check, and deserve more time, tokens, or permission next time?

  • Evidence over vibes
  • Review cost visible
  • Next investment explicit

Proof rails

Four rails keep the loop inspectable.

The rails are the visitor's checklist. They separate a real product loop from resume polish: problem, build, evaluation, and memory each need a public signal.

01Problem rail

What real workflow pain started this?

Build-log receipts connect shipped artifacts to the reason a stranger should care.

02Build rail

What exists outside the chat?

Demo routes and public repos make the work openable instead of anecdotal.

03Evaluation rail

How is agent work judged?

Agent Scorecard frames artifacts, tool use, verification, and review burden as the trust test.

04Memory rail

What compounds into the next loop?

Digital Twin and Knowledge Harness keep the public story tied to reusable operating rules without publishing private notes.

Public proof links

Openable artifacts, not private session lore.

Walk the compact demo

Four public stops: operating layer, evaluation layer, model access, proof surface.

Open proof

Scan recent ships

Receipts for what shipped, why it matters, verifier signal, and boundary.

Open proof

Open Agent Scorecard route

Compatibility route pointing to the evaluation layer inside the compact demo.

Open proof

Open Agent Scorecard repo

Trace-first standard for judging agent work by artifact quality and review burden.

Open proof

Open CLIProxyAPI repo

Model-access infrastructure for CLI and coding-tool provider routing.

Open proof

Read Digital Twin page

The operating-layer thesis behind the file-first product loop.

Open proof