The web workspace is both a human governance interface and a structured agent tool host. Every product capability needs an MCP or CLI route, but authority is not flattened: agents may read, explain, prepare, and propose; authority-bearing changes must end in a clear owner review surface. Never disguise a prepared draft as an active setting. The UI must say what the agent prepared, what has not happened, and the single human action that makes it effective.
WebMCP tools should follow the visible workflow rather than expose a parallel admin API. Read tools orient and inspect; executable checks may append receipts but must report that no approval occurred; sensitive or authority-bearing work is prepared into the corresponding owner UI. Tool annotations must identify read-only calls and untrusted ledger content. Credentials and provider secrets never appear in tool results.
Status (2026-09-07): Canonical design guidance. Boardroom Clarity is the accepted visual system for Proofpress product UI, presentations, public editorial material, diagrams, and infographics. Product UI uses the shared shadcn component layer and must pass the localhost interaction review defined below before release. Local browser validation is implementation evidence, not deployment or partner-outcome evidence. Product hosts may supply their own brand shell, but trust states and evidence semantics remain consistent. The owner MVP excludes assistant/chat entry points.
The owner workspace keeps its 224px navigation rail and flexible primary work surface. Review pairs its queue with a contextual inspector; Knowledge uses a searchable library and a spacious claim record rather than requiring the same inspector on every page. Home leads with the next decision and current knowledge. At widths below 1100px, opening a Knowledge record replaces the library until the reader closes it; focus returns to its opening control or search.
Hosted Workspace V2 adopts the original dashboard reference's information architecture only. Boardroom Clarity is the accepted visual baseline: a white institutional canvas, near-black ink, fine rules, restrained Proofpress teal, DM Sans display and task typography, and IBM Plex Mono for proof metadata. Knowledge starts with current eligible claims and opens their evidence, use conditions, and recorded human authority. Local lineage is a secondary inspection path. Legal-specific vocabulary and demonstration claims are not copied into the product. The current owner extension remains a local implementation awaiting human visual review; its surface brief is .impeccable/surfaces/web-owner-index-html.md.
Use shadcn primitives as the required accessible construction layer for every interactive product surface. Buttons, inputs, textareas, selects, cards, tabs, accordions, dialogs, radio groups, checkboxes, tables, badges, pagination, tooltips, and loading or empty-state containers must come from, or extend, the shared web/owner/src/components/ui/ layer. Do not create page-local imitations or place legacy form and disclosure markup inside a shadcn shell. Reduce the default radius and shadow, keep one consistent control height, and build hierarchy primarily with type, alignment, and rules. A component that looks recognizable as an unmodified starter-kit component is unfinished.
Every frontend change follows this sequence:
- Read this document,
PRODUCT.md, and the matching.impeccable/surfaces/brief before editing. - Work on an isolated local branch or worktree. Keep the change unpushed, unmerged, and undeployed while visual review is pending.
- Build with shared shadcn components and design tokens. DM Sans is the default for navigation, headings, prose, labels, and controls. IBM Plex Mono is limited to raw IDs, hashes, versions, code, receipts, and sparse proof indexes.
- Run unit tests, type checking, the production build, and the Impeccable detector.
- Exercise the complete product workflow in a real browser. Visit Home, Review, Knowledge, Runs, Activity, and Admin; open every tab, accordion, disclosure, dialog, record, filter, pagination control, empty/loading/error state, and available decision path. Verify at 1536×1024, 1024px-wide, and 390×844.
- Review screenshot evidence for typography, spacing, overflow, hierarchy, keyboard focus, mobile safe areas, and the authority boundary. A shadcn outer component containing visually inconsistent legacy content fails review.
- Start a stable localhost preview using the persistent synthetic dataset and owner credential. Richard reviews the actual workflow there.
- Push, open or update the PR, bypass required checks, merge, and deploy only after Richard explicitly approves the localhost result. A backend bypass or approval from an earlier frontend change does not carry forward.
The agent completing the change reports the routes and states inspected, defects fixed, test and browser results, remaining limitations, and whether any push or deployment occurred.
The desktop reference viewport is 1536×1024. The primary table begins on the same vertical axis as its title and filter row; the contextual inspector begins at the application header and owns its own scroll. Selection is expressed through the canonical accent-soft wash and a one-pixel cyan marker, never a glow. The mobile reference viewport is 390×844, where tables become structured records and the decision controls form a safe-area-aware bottom bar.
Hosted Workspace V2 does not define a second palette. It uses the canonical tokens below: paper/card #FFFFFF, ink #181A20, secondary ink #555B66, readable metadata ink #686F78, line #D7DCD9, accent #0E6675, and accent-soft #F4F8F8. Needs revision uses revision #665A8A on revision-bg #EFEDF5. Red means rejected/blocked or destructive access operations. Green means admitted, active access, or a specifically confirmed operation such as clipboard copy; each must have an explicit label. Needs review uses the labeled cyan review treatment; labels and structure must preserve its distinction from selection or admission.
In one phrase: boardroom clarity for governed context. A white institutional surface, ink-colored text, precise rules, and one cyan-blue accent govern interaction. Semantic colors describe verification and review state; they are never decoration.
Proofpress interfaces make one boundary legible: evidence and model recommendations can support a candidate claim, but only policy-compliant human admission makes it governed context. Information density serves that decision. Show the claim before its machinery, the evidence bundle before raw sources, and pending work before completed work.
The public landing page is a persuasion surface in the existing Boardroom Clarity identity. Its information architecture is: trust bottleneck → compounding risk → handoff problems → existing-stack gap → four-step mechanism and synthetic handoff specimen → separate architecture → qualified teams → bounded study → commercial partner invitation → collapsed local evaluation → published writing → brand film → final contact. Each section should make one claim and earn the next scroll.
- Lead with one plain-language promise and two distinct actions. The primary action, “Join as an early design partner,” anchors to the commercial invitation at
#partners; the secondary action opens the GitHub repository. The partner invitation and final contact action open the public Notion intake form. - Keep the four-step lifecycle on the dark product section, followed by a narrative handoff example and warm-paper claim specimen. Clearly label its synthetic evidence; show the proposer, human admission, permitted use, and excluded use, with attached evidence behind a native disclosure. Keep the separate architecture diagram focused on evidence, three gates, four interfaces, and downstream reuse.
- Name the current ICP without implying validation: AI NeoLabs; AI-native professional services in legal, accounting, and consulting; regulated vertical AI in banking, insurance, and healthcare; and knowledge-intensive R&D in pharmaceuticals and biotech.
- Use authored editorial media for the hero, native SVG for the explicitly illustrative compounding chart, HTML/CSS for the architecture and study visualization, and real article/video assets later in the page. Generated atmosphere must not replace trust semantics.
- Keep public evidence bounded. The paired dot plot shows seven models ordered by uplift on an explicitly zoomed 75–100% rubric-completion scale, with numerical values and accessible descriptions. Distinguish 126 paired quality runs from 63 controlled stress pairs for unsafe propagation. Preserve the Harvey LAB-derived source and limited-study caveat beside the results.
- Give the partner invitation priority over technical setup. Present hosted/managed and self-hosted options as topics for discussion. Follow it with a native disclosure, collapsed by default, containing the three-step Skill → MCP/CLI → synthetic workspace evaluation path; retain prerequisites, copy controls, expected outcome, and the separate contribution link inside that disclosure.
- Preserve Boardroom Clarity responsively: editorial splits on wide screens, a single reading column on mobile, DM Sans for persuasion and task typography, IBM Plex Mono for proof metadata, and one cyan accent on a white institutional canvas.
The design system is workflow-neutral. A legal product may organize work by organization, matter, and data room; a research product may organize it by project, run, and artifact. Those host structures are not Proofpress primitives. Proofpress owns the visual language for evidence, candidate claims, review receipts, admission state, trusted context, and lineage between them.
The Trust Boundary Rule. A surface must never imply that retrieval, deterministic integrity, a model recommendation, or staging alone authorizes reliance. Governed context begins only after the configured admission gate succeeds.
Proofpress should feel like a board paper carrying a cyan seal: composed enough for a consequential decision, exact enough to audit, and calm enough to read closely. It is institutional, not bureaucratic; archival, not ornamental; quiet, not empty. A reviewer examines a record rather than operating a dashboard.
The hosted owner workspace is a steward's desk over that ledger. Home orients the human without a chat entry. Cyan is the seal and the interaction, never a substitute for admission.
Do not optimize for "looks like a 2026 AI product." Optimize for this: a future agent or human can tell, in one glance, what they may rely on, why, and under whose authority.
The current owner MVP navigation is:
- Home — next candidate decision and available knowledge; no assistant or chat entry
- Review — governance inbox
- Knowledge — searchable current eligible claims; the stable route remains
/ledger - Runs — task, retrieved context, declared reliance, outputs, and later observations
- Activity — consumption receipts
- Admin — principals, credentials, policy
Admit is the lifecycle verb. Approve is the owner-chrome label for that same decision; the control must keep data-decision="admit". The assistant may explain, query, navigate, and draft a bounded clarification request. It must never admit, reject, or appear to.
A future host may add an assistant through a separate product decision. It is not part of the current owner MVP or an admission authority.
These patterns make Proofpress look like generic AI software and hide the trust boundary. They are defects, including when a host is exploring:
- Decorative gradients, glow, glassmorphism, or aurora backgrounds. Paper is flat.
- Ad hoc font families, sizes, weights, uppercase kickers, or tracked labels in operating UI. Use the role-based type system below; keep editorial typography outside task content.
- KPI tiles, sparkline dashboards, or metrics-that-look-important as Home.
- Sparkle, magic-wand, or ✦ as a mark of authority. A host may use a small mark on the Ask Proofpress toggle; it must never sit on Admit/Approve, a status chip, or a candidate claim.
- Green, red, or orange used for decoration or visual variety. A green copy confirmation or Active credential label confirms only that operation, never knowledge admission.
- Draft as a Proofpress lifecycle term. A proposal is a candidate. Draft belongs to documents, not admission state.
- Copy that treats Ask Proofpress, a model recommendation, or a passing check as admission.
- Linear or ChatGPT chrome: infinite chat as the product, stacked elevated cards, gradient pills, or confidence percentages as authority.
- Image generation or video generation as product UI. Trust states must remain recognizable without generated atmosphere.
When an agent proposes visual work, run a critic against screenshots only. Do not put the stop criterion in the critic prompt.
Taste bar. Would this still look like Proofpress if the logo were covered? White institutional canvas, ink, one teal accent, decisive DM Sans hierarchy, and IBM Plex Mono only for raw proof identifiers and indexed metadata. If the page mixes unrelated typographic treatments, it fails.
Trust bar. Can a stranger point to the candidate, the evidence, the checks, the advisory recommendation, and the human decision — and see that only the last one admits? If Ask Proofpress, a green check, or a cyan glow could be mistaken for admission, it fails.
References. Use the brand-film stills and the hosted owner surfaces as the visual references, not a moodboard of other products.
Output. Numbered findings, each with a screenshot crop description, the rule it violates, and a concrete fix. Separate taste misses from trust-boundary misses. Do not congratulate. Do not invent a new IA.
The human, not the critic, decides when to stop. A critic that is also asked "are we done?" will say yes.
//: # (ob:451376f2)
| Token | Light | Dark | Use |
|---|---|---|---|
| paper | #FFFFFF | #15171C | Default institutional canvas |
| ink / ink-2 / ink-3 | #181A20 / #555B66 / #686F78 | #E9E7E0 / #A6A9B4 / #8F939D | Primary / secondary / readable indexed metadata |
| line | #D7DCD9 | #2C2F38 | Rules, connectors, and inactive boundaries |
| card / wash | #FFFFFF / #F5F6F5 | #1D2027 / #22252D | Working surfaces / quiet hover wash |
| accent / accent-soft | #0E6675 / #F4F8F8 | #5FB3C4 / #173741 | Proofpress brand, action, selection, and labeled needs-review state |
| add / add-bg | #2F6B54 / #EDF5F0 | #6FBF8E / #1B3226 | Verified checks, admitted claims, active governed context |
| del / del-bg | #963F38 / #F8EEEC | #C87E82 / #3A2320 | Rejected, invalid, blocked, removed |
| review / review-bg | #0E6675 / #F4F8F8 | #5FB3C4 / #173741 | Candidate and needs review, always paired with an explicit status label |
| move / move-bg | #665A8A / #EFEDF5 | #AAA0D2 / #29263A | Moved content only; never review state or generic attention |
The launch film remains a narrative reference, but the operating UI uses a quieter light-theme subset: white carries primary content, cyan carries Proofpress interaction and the explicitly labeled needs-review state, red carries rejected or blocked, and green is reserved for verified or admitted. Moved content may use muted violet. Yellow/orange is not an interactive control, status, recommendation, or attention color in the hosted owner workspace. Dark narrative artifacts may use the documented dark counterparts, but product UI defaults to the white Boardroom Clarity canvas. Both themes must be proofread.
The State, Not Brand Rule. In governance records, green means admitted, red means rejected/blocked, muted violet means needs revision, and labeled cyan means needs review or advisory evidence support. Outside governance, an explicitly labeled green Active badge or clipboard confirmation is permitted, not an admission signal. Do not use semantic colors for decorative emphasis or visual variety. Cyan may identify Proofpress, primary actions, and review, but it cannot make a candidate appear admitted.
The fixed fallback mapping for GitHub PR comments is 🔵 mod, 🟣 mov, 🔴 del, and 🟢 new. Blue is the closest GitHub emoji equivalent to the cyan accent; purple deliberately replaces yellow for moved, so an ordinary move is not misread as a warning. branding.color: blue in GitHub Action metadata controls only the action icon background in Marketplace/Actions lists; it does not control PR comments.
- Owner page title:
--font-ui(DM Sans / system sans), fluid 2.25–4.75rem where space permits, weight 600, tight line-height and tracking. The title carries hierarchy without a decorative kicker. - Section, dialog, inspector, and scope headings:
--font-ui,--type-section1rem, weight 600, line-height 1.5. - Claims, evidence excerpts, controls, and prose:
--font-ui,--type-body.875rem, weights 400–500, line-height 1.5–1.6. Dense operating text uses this role; sustained editorial documents may retain their separate reading typography. - Metadata and labels:
--font-ui,--type-meta.75rem, weight 400, line-height 1.5. Compact badges are an explicit 11px dense-label exception. - Indexed labels and proof values:
--font-mono(IBM Plex Mono / system monospace) is reserved for raw IDs, hashes, versions, code, receipts, and sparse institutional index labels such asAVAILABLE NOW,NEEDS REVIEW,SOURCE 01, andPROPOSED REUSE BOUNDARY. Indexed labels may use 10px uppercase with restrained tracking; ordinary navigation, status chips, paragraphs, and metadata remain UI sans. Browser zoom and text scaling must remain usable; prose should stay within approximately 45–75 characters per line.
The Role, Not Component Rule. Components consume shared font and size tokens; they do not invent local type ramps. IBM Plex Mono indexes the institutional record but never becomes a technical costume for ordinary copy. Slides and editorial documents may use a compatible serif for a bounded quotation or long-form reading passage. Proofpress titles, propositions, controls, and diagrams use the canonical DM Sans hierarchy.
Boardroom Clarity is one system with four expression modes, not one app stylesheet stretched across every artifact:
- Operate UI: dense, task-first, rectilinear, accessible, and state-explicit. Color primarily carries action and governance status.
- Presentation: one proposition per slide, large DM Sans hierarchy, generous white space, fine black rules, and one purposeful cyan diagram or emphasis. Avoid ornamental dashboards and card grids.
- Public editorial: strong thesis-led typography, real product or evidence imagery, restrained cyan indexing, and prose designed for reading rather than feature marketing.
- Data and infographic: begin with the claim, bind every visual claim to a source, use direct labels, and reserve green/red for admitted or rejected/blocked states. Cyan may show Proofpress flow or review, but never imply admission by itself.
The One Argument Rule. Every composition should make one principal claim legible before its supporting machinery.
The Evidence Before Ornament Rule. Diagrams, charts, and visual accents must explain provenance, authority, comparison, or sequence. Decoration that could survive after the evidence is removed does not belong.
The Medium, Same Meaning Rule. Layout may change across UI, decks, editorial pages, and infographics; the meaning of cyan, green, red, violet, rules, type roles, and the Proofpress mark does not.
- Focused review: single reading column with a maximum width of 760px and body lines no wider than 70 characters. Use the order navigation → metadata → claim → recommendation and checks → evidence → decision.
- Review with a human gate: a flexible reading column may pair with a fixed 320–344px decision or receipt panel. Keep the claim and its evidence visually dominant.
- Knowledge library and record: browse readable statement rows with search, applicability filtering, and proposal-date or alphabetical sorting. At desktop widths, the library and record share the work surface; at 1099px and below, the record becomes the sole reading surface. Keep proposer, admitting reviewer, permitted uses, and validity conditions visible before the evidence and history disclosures. Missing fields are explicitly unrecorded, never inferred as unrestricted permission.
- Local lineage: a bounded canvas may pair with a 300–320px inspector. Read left to right as Bound Evidence → Candidate Claim → Governed Context. Use a subtle 21px dot grid only when it materially improves spatial orientation.
- Responsive: stack reading and decision surfaces on narrow screens. In Knowledge at 820px and below, local lineage becomes a vertical evidence → claim → context sequence with readable nodes and a visible admission boundary; preserve state and keyboard order.
- Rendered artifacts: Markdown tables, lists, bold text, code, and citations must render as content. Exposed raw markup is a defect.
The Reading Order Rule. Orientation → proposition → support → decision → receipt. Progressive disclosure may reveal more detail, but it must not reorder the trust argument.
Proofpress is flat by default. Hairline rules, paper/card contrast, and quiet washes establish hierarchy. Reserve small shadows for sticky decision surfaces, selected-node emphasis, floating contextual assistance supplied by a host, and literal source-document paper. Do not give every evidence block or graph node its own floating card shadow.
Node selection may use a two-ring cyan focus halo without changing node dimensions. Hover may translate an interactive lineage node by at most 2px and must be disabled under reduced-motion preferences.
The Ledger, Not Dashboard Rule. Structure comes from indexing, rules, reading order, and receipts—not layers of elevated cards, telemetry tiles, or decorative gradients.
Records, tables, evidence rows, and source material remain rectilinear. Use 7–8px radii for controls and compact graph nodes, 10px for bounded recommendation surfaces, 12px for a decision panel or the outer lineage workspace, and full pills only for status chips or a host-supplied floating assistant.
Connectors are two-pixel paths with no arrowheads unless direction would otherwise be ambiguous. Evidence-to-claim connectors are quiet solid rules. Candidate-to-context connectors encode the admission boundary: gray dashed while pending, muted blue dashed while revision is requested, red dashed while blocked or rejected, and solid green only after admission. Back to overview uses a leading left arrow and text, not an ambiguous icon alone.
The Visible Boundary Rule. The connector, destination node, inspector copy, and available action must agree. Never draw a solid path into governed context while the claim is pending, blocked, rejected, expired, superseded, or awaiting revision.
The owner workspace uses web/owner/src/components/ui/icon.tsx as the only application icon entry. It renders the official @hugeicons/react + @hugeicons/core-free-icons Stroke Rounded set, bundled locally: default 20px, stroke 1.6, currentColor, decorative icons hidden from assistive technology when their control already has a label. No runtime CDN, API key, or mixed Lucide/Hugeicons family. The official Proofpress logo remains a brand asset, never a generic icon replacement.
Shared owners: ui/button.tsx and ui/badge.tsx consume palette tokens; ui/modal-surface.tsx owns dialog geometry/accessibility; review-feedback.tsx owns DecisionNotice, RevisionPanel, clipboard handoff, and history identity; ledger-overview.tsx owns the bounded workspace support graph; lineage-graph.tsx owns focused nodes, curves, and source expansion; governance.css owns their visual rules and typography roles. Reuse or extend these components rather than copying page-specific markup and hardcoded tokens.
Knowledge starts with the server's current eligible owner projection, rendered by knowledge-library.tsx with search, applicability filtering, and sorting from knowledge-model.ts. A selected claim opens a readable record; evidence and history remain inspectable through disclosures. View lineage opens focused provenance with at most three initial sources, then incremental expansion. A reuse-boundary node must add recorded scope, authorizer, or exclusion reasons rather than repeat a status badge. Rejected or revision history never enters this current-knowledge projection merely because it is recorded. The signed-in owner's eligibility is not a claim about every agent's eligibility. Local fixtures are visibly synthetic. Validate desktop/mobile, keyboard access, long content, clipboard denial, and real receipt states before promoting the build; record implementation, internal dogfood, and partner evidence separately.
- Status chip: compact sans-serif label using the shared Badge. Admitted/current is green; needs review uses labeled cyan on accent-soft; needs revision is muted violet; blocked/rejected is red. Decision history tables display status explicitly, without requiring selection. Pending and recommendation surfaces must not use yellow/orange. Never express authority through confidence percentages.
- Diff tag: compact inline marker. New is green, modified cyan, removed red, and moved violet.
- Evidence bundle: the reviewable support unit for a claim. Summarize its bound evidence blocks and source count; do not present the bundle as a raw file.
- Evidence block row: filename or artifact identity, verified locator, bounded quotation, integrity state, and a clear route to the immutable source. Use a bottom rule instead of an independent promotional card.
- Candidate claim: state, proposition, evidence count, recommendation, and material impact. Its review state must remain distinct from deterministic integrity and model evaluation.
- Review panel: presents recommendation, deterministic checks, evidence sufficiency, and explicit Approve / Request changes / Reject consequences. Keep the human decision available without obscuring the record.
- Admission receipt: replaces decision controls after approval and records reviewer, decision, ledger head or version, timestamp, and append-only history. A success message without projected ledger state is incomplete.
- Governed-context projection: contains only admitted and currently applicable knowledge. Blocked, pending, rejected, expired, superseded, and needs-revision claims may remain auditable but must not appear available to downstream consumers.
- Source viewer: preserves original identity, digest, locator, and citation highlight. Moving from evidence to source must preserve orientation and provide a clear return path.
A lineage view is an inspectable trust path, not a free-form network graph. Default to the selected claim's local provenance. Bound evidence nodes converge into the candidate claim; the final edge crosses the human-admission boundary into governed context.
Clicking or keyboard-activating a node first updates a persistent inspector with node type, identifier, state, integrity or receipt information, and one explicit next action. Evidence opens the bound excerpt before the raw source. A candidate opens review or history. Governed context opens the exact downstream projection only when admitted; while pending it remains inspectable but visibly unavailable.
The Local Lineage Rule. Render the smallest graph that answers “why can this claim be trusted?” Expand through selection, filtering, or a separate ledger projection—not by loading the entire knowledge graph into the default canvas.
The canonical review states are candidate / needs review → admitted, needs revision, rejected, or blocked. A revised claim is a new version with preserved lineage; it is not a silent edit of the reviewed proposition. A rejected claim may be corrected only by a new candidate carrying reproposal_of; the prior rejection stays append-only, the predecessor must be rejected in the same scope, the successor must bind at least one new evidence reference and explain its response in qualifiers.reproposal_response, and it requires fresh checks, advisory review when configured, and a new human decision. Reject and request-changes decisions require a durable human note so the remediation target is never implicit. Only an admitted, current claim may enter governed context.
Every mutation must produce immediate, consistent feedback: prevent duplicate submission, show loading/error state, and project the recorded result through queue, claim, history, and context. Review separates Needs review, Needs revision, and Decision history; deep links select the matching group and switching groups clears an unrelated inspector. The shared DecisionNotice appears at the top. Request changes opens the shared ModalSurface and attempts clipboard copy; claim success only after the browser confirms it. If denied, offer explicit copy or manual selection. No agent is notified or awakened automatically. The agent receives pasted instructions, submits a linked new proposal, and the owner reviews it again. RevisionPanel shows the requested change, one copy action, and actual revised proposals only; long instructions appear only for manual-copy fallback. History displays recorded proposer/verifier/judge/model/reviewer identities; missing identity is explicitly unknown. Deterministic policy evaluation, optional LM advice, and owner admission remain separate.
Decision hierarchy. The review surface shows three explicit layers in this order: deterministic checks, LM advice, and human authorization. A failed check names the missing or invalid requirement in recovery language; never display a false check name as though its presence caused the block. LM accept is labeled Evidence supported, uses the action/advisory color rather than admission green, names its provider/model and criteria version, and never enables admission by itself. The owner action is labeled Approve; approval records the human decision and admits the claim to current knowledge only when every required condition passes.
Hosted review policy. Owner-only settings are workspace-scoped, versioned, audited, and persisted server-side. They control off/manual/automatic LM review, provider and model, bounded workspace criteria, external bounded-evidence consent, and whether current supporting advice is required before approval. The recommended first-run template is automatic review with required advice, but it remains inactive until the owner explicitly configures a provider, credential, criteria, and data handling. Provider credentials are encrypted at rest, write-only in the UI, and never enter policy history or model packets. Automatic review evaluates the existing pending queue when a policy is activated and evaluates new proposals after deterministic checks. A failed current deterministic evaluation is Blocked, leaves the human queue, and never calls the model. Review jobs are durable and idempotent, never admit claims, and do not silently retry an interrupted provider call.
The Review inspector exposes one primary action for the current state. Before checks pass, that action is the required recovery step. After checks pass, Open full review is the solid cyan primary action; manual LM review is explicitly optional and remains a secondary outline action. A policy may require current supporting advice before approval, but it must never make the candidate record itself inaccessible. The proposed reuse boundary includes the complete recorded Relevant when and Validity conditions lists in both the inspector and full review; absent conditions are marked not recorded. The queue and inspector scroll independently on desktop; selecting another claim resets the inspector to its summary.
Semantic activity. Activity is an owner-readable history of knowledge work: which actor submitted evidence, proposed a claim, ran deterministic checks, requested LM advice, made a human decision, revised knowledge, or retrieved governed context. It distinguishes the initiator from the verifier, judge, or authorizer. A retrieval record says retrieved, never used. Raw request outcomes remain available in a separate Technical logs view and do not dominate the default activity feed.
Selection loading preserves list and inspector geometry; it must not collapse and recreate columns. Never show a previous record's actionable receipt as if it belonged to the new selection. Copy success is a borderless green check with explicit text, shown only after clipboard success; failure retains manual fallback. Primary actions—including Approve—use Proofpress cyan, secondary navigation and optional analysis use outline/ghost, admitted state uses green, and destructive actions use red. An Active credential badge is a non-interactive state, not an Activate button. Admin labels are Agent identity (recorded author, e.g. agent:claude-code) and Key name (recognizable device/client label); underlying principal IDs and authority rules remain unchanged.
Status badges share the same neutral one-pixel border; semantic meaning comes from the tinted fill and text, not a heavier outline. Underline tabs reserve their border space in both states and keep font weight, height and baseline fixed, including Evidence/Checks/History. Admin desktop fields and their primary action align on the input row; helper text sits below without pulling the action down. Narrow layouts stack deliberately and separate the brand from workspace identity. Cross-page navigation starts at the top; returning from full review preserves the review position. Graph column labels align with their nodes, and narrow graph canvases indicate sideways scrolling. Activity results describe requests, not claim lifecycle: Recorded is neutral, access/request failures red, and version or duplicate conflicts muted blue. Preserve the recorded error code and never infer an admission decision from request success. Release QA must traverse Home, all Review groups and full details, Ledger overview/focus/current knowledge, Activity and Admin at 1536, 1024 and 390 pixels, with isolated decisions, revision handoff, denied clipboard, credential lifecycle, stale writes, failed loads and keyboard return paths. Never use partner data to manufacture test states.
- Change block: use a three-pixel semantic edge and a light wash. Put word-level changes inside a collapsed disclosure so the document remains readable.
- Comment card: use a semantic edge, card surface, and quiet status copy such as “Awaiting response,” “Recorded · awaiting revision,” or “Resolved.”
- Block hover: reveal a wash surface and an explicit Comment affordance. Clickability must never depend on hover alone.
- Decision bar: when a focused single-column review needs persistent actions, use a sticky bottom bar with solid green Approve, an ink-on-paper Reject control, and a cyan-outline Request changes control. Never use yellow/orange for a decision. State must change immediately after submission to prevent repeated action without feedback.
Use product-facing trust terms: Source, Evidence, Candidate Claim, Review, Admit, Request changes, Reject, Receipt, Ledger, Lineage, and Governed Context. Reserve storage or implementation terms such as event, ref, blob, projection algorithm, and lock for developer diagnostics. Host chrome may label Admit as Approve; the lifecycle event, API, and data-decision value remain admit.
English is the source language for UI strings, CLI output, and documentation surfaces. Interfaces may adapt through Accept-Language, with Chinese as the first locale. Stable Proofpress vocabulary—especially Evidence, Claim, Review, Admit, Receipt, Ledger, Lineage, and Governed Context—must retain one documented mapping across locales and host products.
- Do preserve progressive disclosure from claim to evidence bundle to bound excerpt to immutable source.
- Do keep deterministic integrity, model recommendation, policy outcome, and human admission visibly separate.
- Do make selected graph nodes keyboard-operable and expose the same receipt information without relying on color alone.
- Do project a recorded admission consistently across review, ledger, lineage, history, and governed context.
- Do let a host product apply its own brand shell while retaining Proofpress trust-state semantics.
- Do keep current owner navigation as Home, Review, Knowledge, Activity, and Admin, retaining
/ledgeras Knowledge's stable route; do not restore assistant/chat entry points as a design cleanup. - Do fail closed: unavailable data or invalid lineage must render as blocked or not ready, never as a plausible placeholder.
- Don't treat evidence as synonymous with a raw source file.
- Don't use an unbounded force-directed graph as the default ledger view.
- Don't show pending, blocked, rejected, expired, superseded, or needs-revision knowledge as available to an agent or API.
- Don't make evaluation metrics, model confidence, or recommendation the visual equivalent of admission.
- Don't treat Ask Proofpress, a passing check, or a cyan glow as admission.
- Don't use Draft as a Proofpress lifecycle term for a candidate claim.
- Don't use Inter as narrative type, decorative gradients, or KPI tiles as the Home metaphor.
- Don't bake legal-specific matter, counsel, or data-room concepts into Proofpress core components.
- Don't expose mock counts, synthetic receipts, or hardcoded lineage without an explicit preview label.