What all Veristate can be — the design of a trust platform wearing a marketplace as its front door.

Six decisions that shape everything downstream

Every design choice in this document traces back to one of these. When two options tie, the principle breaks the tie.

Five layers, one direction of dependence

Surfaces depend on services, services on the graph, the graph on the engine, the engine on the rails. Nothing reaches down more than one layer; nothing reaches up at all. Hover any element.

The objects the graph is made of

Sixteen objects carry the whole platform — the four finance objects get their own section (11). The two that make Veristate different from every incumbent are Credential (verification as a first-class, portable, monitored object) and ReliancePact (the legal agreement that lets other businesses consume it).

Verification as a living state, not an event

The engine's defining behaviour: a check runs once, then monitoring keeps it true. Every incumbent re-runs checks per transaction because their result is a PDF. Ours is a state machine with subscriptions.

Party verification lifecycle

Attention is the state that matters most. Point-in-time systems have only "valid" and "expired"; the gap between those is where fraud and deal collapse live. Veristate surfaces degradation early — to the user, and (with consent, under pact) to any party currently in a deal with them.

The check plans

Badge integrity — making the tick unfakeable

Surface one: where the tick earns its meaning

The flagship's information architecture is deliberately small — five areas — because the product's depth lives in states, not screens. These six wireframes seed the Phase 0 prototype; each maps to a use case from the investor proposal.

Surface two: their brand, the shared graph

The white-label's central design decision is what is tenant-scoped and what is network-shared. Get this wrong one way and there is no network effect; wrong the other way and no agency will sign.

Technically the white-label is the flagship webapp with a tenant context: same code, tenant-resolved tokens, feature flags per plan. A lightweight embed SDK (badge widget, verified-offer button, pack viewer) lets tenants keep their existing website and bolt trust onto it — often the first step before a full co-branded deployment.

Surface three: Veristate as something an AI can act through

The API is the platform's real boundary — the webapp and white-labels are its first two clients. The MCP server is a thin, opinionated projection of the same API for AI assistants, designed around one rule: an assistant may gather and prepare anything, but binding actions require a human ceremony.

Resource surface (REST, versioned, consent-scoped)

The MCP server

Tools are named for intent, not for endpoints, and each declares whether it is read, prepare, or ceremony class. Ceremony-class tools never complete an action: they stage it and return a signed link where the human confirms inside a Veristate surface (webapp or white-label) with their verified session. The assistant's context receives reference tokens and summary bands — never documents, balances, or identity data.

Why this matters strategically: as buying journeys move into assistants, the assistant needs a counterparty it can trust programmatically. Portals offer HTML to scrape; Veristate offers signed claims. The MCP surface is how "the trust layer for AI-assisted property" stops being a slogan and becomes an integration.

Surface four: the professional's daily driver

The Cowork plugin composes the MCP server with packaged skills — prompts and workflows tuned to four professional teams. It ships no logic of its own beyond these compositions, so it inherits every platform improvement for free.

Design rule inherited from section 07: the plugin's agents read and prepare; humans confirm ceremonies. A morning brief can notice, draft, and stage — it cannot bind a client to anything.

From accepted offer to registered title, with the ball always visibly held

The Deal state machine is Veristate's answer to the fragmented downstream chain. It does not perform legal steps — it sequences them, pre-fills them, and makes their state legible to everyone entitled to see it.

Failure paths are first-class: a crashed condition reverts the Deal to market-return with the pack and both ticks intact — relisting is hours, not weeks, which materially softens the cost of a fall-over for both sides.

Practitioners as first-class citizens, not a referral afterthought

Today buyers find conveyancers via agent referral — late, opaque, and conflict-prone. The panel redesigns that relationship around three commitments.

Conflicts policy: tenants may pin preferred firms, but every recommendation surface discloses the relationship, and the consumer's own choice always outranks the pin. Referral economics are flat-fee per appointment — never a percentage — to keep incentives clean.

Buyers, brokers, lenders — two many-to-many edges with pricing on top

Finance is the platform’s second marketplace. Buyers reach multiple verified brokers; each broker reaches multiple lenders through an accredited panel; lenders feed products, policy and pricing into the graph. Veristate owns the plumbing between them — consent, matching, comparison — and the evidence trail the law demands. It never touches the money: commissions stay between broker, lender and client, disclosed on every quote.

The four finance objects

Lender feeds

Panel pricing — a pure function

Matching is deterministic, versioned and replayable: "why did it rank this way on 12 August" must be answerable forever, because a regulated adviser recommends from its output. No stored ranking — like the tick, matches are computed on read and logged on use.

match(scenario, clientFile, panel) → ranked product set

  # 1 · eligibility — policy filters (LVR cap, income type, security rules)
  #     exclusions are KEPT, with reasons: BID needs the considered set, not just winners
  eligible, excluded = screen(panel.policies@version, scenario, clientFile)

  # 2 · serviceability — income × policy factor ÷ lender buffer, vs loan
  for p in eligible: p.buffer_ratio = capacity(clientFile, p.policy) / scenario.loan   # pass / tight / fail

  # 3 · pricing — carded rate + scenario adjustments (LVR band, IO, fixed) − likely discretion
  for p in eligible: p.rate = card(p, scenario) − discretion_outlook(p, clientFile)

  # 4 · rank — 5-year true cost, tie-broken by client objectives (offset need, certainty, speed)
  return rank(eligible, by=true_cost_5yr, tiebreak=clientFile.objectives), excluded

Every scenario change a broker makes — a slider move, a repayment toggle — re-runs the function and appends the inputs, policy versions and output to the LoanCase log. That log is not overhead; it is the raw material of the next subsection.

Best-interests calculation and the BID evidence pack

Principle P6 applied to brokers: nobody "does BID paperwork". The Best Interests Duty demands the broker show the considered set, why the recommendation beats it, and how the client’s objectives were weighed — which is exactly what the LoanCase log already contains. The BID evidence pack renders it: considered products (including exclusions and their reasons), the scenario history, the ranking rationale verbatim from the model, the client’s stated objectives, and the commission disclosed on each quote. Generated per file, on demand, regulator-ready — compliance as exhaust.

What each side sees

Action classes follow section 07’s rule: reading a consented file and running matches are read/prepare; a buyer granting consent or proceeding with a broker, and a broker sending a quote, are ceremonies. The AIP attaching to an offer is automatic — it is a credential presentation, not an action.

Designing for the honeypot problem we are choosing to have

A platform holding identity and financial verification for hundreds of thousands of people is a target. The architecture assumes breach attempts and designs so that success yields as little as possible.

Stack, shape, and the path to Phase 0

Boring technology, deliberately: the risk budget is spent on the trust engine's correctness and the integrations, not on infrastructure novelty.

Proposed stack (Python-centred)

Build plan mapped to the investor roadmap

Team shape for Phases 0–1: two backend (engine + integrations), one frontend, one design, fractional legal/compliance counsel — the reliance-pact framework and Identity-Agent appointments are as much "build" as the code.

Decisions this document deliberately leaves open

Next step, as before: Phase 0. Wireframes W1–W6 (W7–W8 follow with the Phase 2 finance surfaces) and the API stubs in section 13 are specified precisely so the prototype can start from this document without another planning round.