What Great Looks Like

v1.2 · 2026-07-11 (v1.2: the VP relationship — jobs done WITH and BY your VP, per-job delegation dial, symbiotic learning system · v1.1: Claude Design canonical, JTBD-fit screens) · the experience standard every slice is measured against — cited in specs alongside AC IDs · sources: po-vision-canon, tier-strategy, connections-design, Clay's own words (Otter, 2026-06-30), the design refs, the standing design rules
The north star, in Clay's words to a client: "I prefer reality to data… it's a real-time shared source of truth. Each node in the network is connected… all of that information is permissioned… it's not that you need to reach out for it — it's there, it's connected, it's live for you… and everything is an ETA until it happens, updating live with the actuals as it goes."

The bar: Bloomberg Terminal for cannabis operations. Mission-critical infrastructure a founder opens with calm confidence — not a dashboard someone has to double-check.

And the relationship that makes it VP (Clay, 2026-07-11): "JTBDs are jobs that you have your VP do, and do together with your VP — supporting the president as much or as little as they would like to be supported, and the president supports the VP. The symbiotic, learning, self-improving system and 'vice-president' they always wanted."

Every job carries a delegation dial: together (VP brings context, president drives) → VP drafts, president approvesVP executes and reports. The dial is set per job, per president — and it moves rightward as the VP earns trust, because every correction and approval teaches it. Support flows both ways: that is the product.

Values — how VP behaves (each earned the hard way)

The experience standard — with exemplars (the pixels, not just the words)

StandardThe exemplar to match
Screen ambition — screens are instruments, not listsThe Connections industry graph (/connections in prod — 3D/2D, stakeholder groups, search-everything). This is the ceiling to aim at, and the floor for "done" is its design ref.
One world; screens are JTBD-fit — the shared source of truth is universal, screens are not automatically. The test: does this stakeholder's job on the object differ, or only their permissions? Permissions only → the SAME screen through the lens (PO Tracker). Different job → a tailored screen on the same world objects (producer cultivation, processor QP release, retailer assortment) — tailored per stakeholder and per role within it. Never fork the data; never rebuild what's shared.PO Tracker via viewer switcher (projection case) · vervana-pro's stakeholder modules + the role-specific JTBDs in the .dc refs (tailored case)
Real data disciplineThe BCP cockpit period-engine (real daily aggregates, May €74,088 — a number with provenance and an audit trail behind it).
Design fidelityThe .dc.html refs in docs/vp-suite/ are canonical per screen (Choreography, Entity Profile, Messages, Data…). Match verbatim; deviations get flagged, never shipped. Design rules: defused reds, no navy-filled cards, brand gates on tenant surfaces.
Copy & voiceVP speaks first person, plainly, with reasoning ("2 of 6 POs need expediting — 2042 leads at 5d late"). Narrative and table must be the same fact. English for people, DE conventions on German tenant surfaces.
The demo worldThe fictional cast (Steinbach, Atlas Verde, Rheinwerk…) is the single canonical world for every demo, fixture, screenshot, walkthrough — deterministic and versioned.

The reference shelf — where everything canonical lives

QuestionCanonical source
Why does VP exist / the network thesis?po-vision-canon/docs/vision/ (platform · data · tier-strategy) + connections-design spec + VIRAL_ADOPTION_STRATEGY
What must be true? (testable)AC-CANON v1.3+ — SPINE/RBAC/ING/LENS/TIER/ARCH/TP
What does each screen look like?Distributor: Claude Design is canonical — the claude.ai design project, synced two-way via /design-sync; its changes flow into Claude Code as canon. Repo-side artifacts: docs/vp-suite/*.dc.html refs. Plus pro.vervana.co (frozen concept, 84 pages) and shipped prod screens.
What does each NON-distributor stakeholder screen look like?pro.vervana.co is the canonical reference — the real built screens for all 12 stakeholders (broker, lab, logistics, customs, market-releaser, remediator, trade-finance, processor, producer, retailer, insurance) live in ~/dev/vervana-pro/app/<stakeholder>/ (on the Hetzner box at ~/vervana-pro-ref/). PORT from these real screens — never paraphrase. PRECEDENCE (Clay 2026-07-12): vervanav4 is AHEAD of pro.vervana.co in many areas (esp. distributor). So: (1) for any SHARED screen, reuse vervanav4's advanced screen via RBAC projection — the distributor's advances propagate up to every stakeholder automatically; (2) fall to pro.vervana.co ONLY for stakeholder-specific tailored screens vervanav4 lacks (CoA workflow, cultivation, QP release, remediation, genetics). Never re-derive an advanced screen from the older concept. They also encode how each stakeholder connects to the spine + the vision. /demo becomes the clean, unified, comprehensive port of all of them. Clay 2026-07-12
What remains to be done?The Completion Board — 86 rows × 5 gates, regenerated, can't lie. Phases: distributor → processor → producer → every other stakeholder lens (ARCH-3) → seams (producer-observer, shop) → clients self-connect sources → live.
How do we ingest & organize data?Ingestion Plan v1.2 (Allan's field-event pattern; FE/BE seam drawn)
What already exists in code?The Atlas (3,074 exports, 71 routes) + BACKEND-CONTRACT.html + FE-SCHEMA-MAP.html
How do we work & improve?The process contract + docs/process/process-log.md — violations flagged in the moment, both sides, Friday trend review. Canon amendments dated, via accept/redo only.

What can be improved (current, honest)

Cited in every codex spec alongside AC IDs from now on. Amend via "amend great: …". · Clay ⇄ Claude · 2026-07-11