Skip to main content
Reality Oracle
OverviewCitizensReality FeedVerified ActorsIntel SubscribersMarket PredictionInvestment FundsHow It WorksGates
Products
Backtest ForensicsLiving MapDrift AlertsPath QueriesCustom AxesRisk Maps
Solutions
Compliance OfficersRisk Managers / CROPortfolio ManagersCTOs & Engineering
Enterprise
Enterprise OverviewReality Oracle · SuperappThe AppsArchitectureAudit ManifestTrust CenterPricing
Developers
DocumentationAPI ReferenceSDKsArchitectureAudit Manifest
Resources
BlogUse CasesCustomer StoriesPressChangelog
Company
AboutFoundersCareersContact
Trust
Trust Center
More
PricingJoin Waitlist
··10 min read

The design partner shapes the POC

Building with, not for — the partner examiner defines the manifest. Anonymized, illustrative.

The design partner shapes the POC

A design partner is not a reference logo. It is the examiner who decides what the manifest has to answer — and the POC is shaped by that, not by a feature list.

This is an anonymized design-partner scenario; the institution is a regulated firm, the figures are illustrative, and no actor has agreed to anything. We are pre-revenue, building the POC. With that label on it, here is what it looks like when the design partner is the one shaping the POC, not the one being sold to.

The examiner defines the manifest

A POC built from a feature list is a POC built in a mirror — the team builds what it thinks an examiner wants. A POC built with a design partner is shaped by the partner examiner: the questions the examiner asks become the manifest fields, and the fields the examiner cannot answer from the manifest become the work. The manifest is not designed in a vacuum; it is designed by the question a real examiner would ask, which is the only honest way to design it.

Illustrative. The examiner question becomes the manifest field: each question an examiner would ask is a column in the record. The POC is shaped by the questions, not by a feature list.
Illustrative. The examiner question becomes the manifest field: each question an examiner would ask is a column in the record. The POC is shaped by the questions, not by a feature list.

Building with, not for

Building for a partner is a vendor posture — a demo, a roadmap, a logo. Building with a partner is a co-design posture — the partner examiner reads the manifest, finds the fields they cannot answer, and the next sprint is the one that fills them. The POC is the manifest the examiner would read, not the demo the sales team would show. That is the difference between a POC that ships a slide and a POC that ships a substrate.

A POC built from a feature list is built in a mirror. A POC built with a design partner is shaped by the examiner — the questions become the fields, and the gaps become the work.

  • The examiner question becomes the manifest field — the POC is shaped by what an examiner would ask.
  • Building with, not for: the partner examiner reads the manifest and finds the gaps; the gaps become the sprints.
  • The POC is the substrate an examiner would read, not the demo a sales team would show.

What the design partner does not get

The design partner does not get a certificate that the POC is accurate. The manifest attests provenance and reproducibility, not truth — and the calibration loop (Gate 1b) is what would earn any accuracy claim, which has not passed. What the design partner gets is a POC shaped by their examiner questions, a manifest that answers those questions, and a loop that is honest about its own gap. The partner shapes the POC; the POC does not oversell the partner. We are pre-revenue, building the POC, and the partner is the one defining what "built" means.

A design partner is not a reference logo. It is the examiner who decides what the manifest has to answer — and the POC is shaped by that, not by a feature list the team wrote for itself.

— design-partner POC note
§Keep reading