TheoremDB Interface System

This document defines the language and visual rules for TheoremDB. It should be used for the design lab, the Problems directory, statement pages, and later page rewrites. Product UI should read like a mathematical index: precise, compact, and calm.

The system takes its typographic restraint and lapis accent from Worldfall. Directory pages take their density and filtering structure from OpenAlex. Permanent identifiers and record pages follow the habits of the Stacks Project and OEIS. Contribution summaries use the compact visibility of MathOverflow.

Product principles

1. Put the mathematical object first. A statement, proof, counterexample, or attempt should occupy more visual space than its metadata.
2. Report the system’s knowledge precisely. Every state label should name the decision that has actually occurred.
3. Keep ordering factual. Name the recorded field used to sort and show the underlying date, count, evidence grade, bounty, or Reputation amount.
4. Use compact lists for collections. Reserve panels and mathematical display blocks for content that benefits from separation.
5. Keep contribution and attribution visible beside the work. Reputation supports the record and never replaces it.
6. Use plain product language. Metaphor belongs in editorial writing, outside controls, status messages, headings, and navigation.

Product voice

The voice is factual and direct. Headings should usually name a page, object, or operation. Explanatory copy should answer a concrete question about scope, evidence, provenance, or the next action.

Preferred patterns:

• Problems
• Proof claimed
• 12 attempts
• Updated 2 hours ago
• This result has two independent reviews.
• Submit a counterexample
• Search statements, problems, people, or identifiers

Avoid motivational slogans, game imagery, and language that personifies the database. These words and phrases are prohibited in product UI:

• prospect, prospecting, prospector
• frontier
• swarm
• gold rush
• strike gold
• treasure
• quest
• adventure
• mathematics worth working on
• interesting theorem, interesting conjecture, and other unqualified uses of interesting
• probably proven
• recorded for the swarm

Technical API names may remain stable for compatibility. The interface presents the labels defined below. Documentation may show an API token in code while using the approved label in prose.

Information vocabulary

Use these nouns consistently.

Term	Meaning	Usage rule
Statement	A canonical mathematical assertion in the database.	Use as the broad record type.
Conjecture	A declarative statement whose resolution is open or partial.	Use when the unproved status is relevant.
Theorem	A statement with an accepted informal proof or a formally verified proof.	Do not call every statement a theorem.
Problem	A request to prove, refute, construct, compute, classify, or explain something.	Use for work-oriented directory entries.
Result	A proof, counterexample, partial result, obstruction, or reproduction submitted against a statement or problem.	Use as the parent category for resolution work.
Attempt	A recorded line of work, including a failed or inconclusive route.	Use in human-facing lists and actions.
Trace	The detailed event sequence, computation log, or agent transcript attached to an attempt.	Use for the inspectable technical record.
Negative result	A reviewed obstruction, failed method, or bounded finding that rules out a useful route.	Use only after the contribution meets the published review policy.
Formalization	A statement or proof expressed in a named formal system and pinned environment.	Always show the system and environment.
Evidence	A source, artifact, computation, review, or formal check supporting one exact assertion.	Show its scope and grade together.
Review	A recorded assessment by a named reviewer or checking service.	Show the reviewer role and date.
Submission	A new problem, conjecture, result, formalization, or revision awaiting a decision.	Use for the review queue.
Attribution	The people and agents credited on a record.	Agents appear as a byline under their owning account.
Credit	A durable receipt tying an account or agent to a contribution.	Use on contribution history and event detail.
Reputation	The account’s lifetime total from eligible events.	Capitalize as a product term.
Quota-eligible Reputation	Final Reputation from reviewed mathematical work that can raise bounded free write capacity.	Show it separately from Lifetime and Available Reputation.
Bounty	Reputation placed in escrow against published acceptance conditions.	Display the amount and conditions together.
Activity	Dated follows, attempts, results, and updates attached to a record.	Show the exact count or event. Never convert activity into a quality claim.

Account and agent credit

The account is the primary public identity and receives Reputation. An agent can receive a visible byline and role credit beneath that account.

Approved byline:

@noether, with algebra-search-2

Approved credit event:

@noether received 40 Reputation. Agent: algebra-search-2. Reason: reproduced obstruction.

Avoid agent-only leaderboard rows unless the viewer explicitly selects the agent view.

Navigation

Primary header

Use this order and these exact labels:

1. Problems
2. Statements
3. Activity
4. Formalization
5. Leaderboard
6. API

The TheoremDB wordmark links to the home page. A site-wide search control sits between the wordmark and primary links when space allows. The right side contains Sign in or the account menu.

Remove Explore and Prospecting from primary navigation. Search and the named directory pages replace Explore. Submissions replaces Prospecting and lives in the account menu and review tools.

Account menu

Use this order:

1. Profile
2. Submissions
3. Reviews
4. Bounties
5. Agents
6. Settings
7. Sign out

Footer

Use these labels:

• About
• How it works
• Evidence policy
• Reputation policy
• API documentation
• MCP setup
• System status
• Contact

Page names and actions

Page names

Route or function	Page title
/	TheoremDB
Universal results	Search
Problem directory	Problems
Statement directory	Statements
One statement	Use the statement’s short title.
Contribution event list	Activity
Submission queue	Submissions
Formal work queue	Formalization
Bounty list	Bounties
Reputation ranking	Leaderboard
Account contribution history	Profile
Developer reference	API documentation

Primary actions

Use a specific verb and object:

• Submit a problem
• Submit a conjecture
• Add a result
• Add a proof
• Add a counterexample
• Record an attempt
• Attach a trace
• Request formalization
• Submit formalization
• Add evidence
• Review result
• Revise submission
• Fund a bounty
• Claim bounty
• Open dispute
• Follow problem
• Copy identifier
• Cite this record

Use Save draft and Submit for review as separate actions in multi-step forms. Use Publish only when the current actor has authority to make a record public.

Secondary actions

• View details
• View evidence
• View history
• Compare revisions
• Download trace
• Copy link
• Report issue
• Withdraw submission

Avoid vague buttons such as Go, Start, Continue, Learn more, and Apply when a more specific label fits.

State terminology

State badges must use the display labels below. API values can appear in developer tools and record metadata.

Publication and qualification

API value	Display label	Supporting text
draft	Draft	Visible to its authors.
submitted	Submitted	Received and awaiting initial checks.
prospecting	Challenge period	Public and open for work. Show the seven-day acceptance deadline.
pending	Under review	A decision has not been recorded.
administrator_review	Staff review required	A person must resolve a flagged issue or judge disagreement.
qualified	Accepted to index	The submission met the published qualification policy.
published	Published	The record is publicly indexed.
merged	Merged	The canonical record is linked beside this label.
archived	Archived	Retained for history and excluded from current results by default.
withdrawn	Withdrawn	Withdrawn by an authorized contributor.
tombstoned	Removed	Public metadata follows the moderation policy.

The submission confirmation leads with the permanent problem number and ID. It gives one public problem link and one Work on this link that opens the research agent with the exact problem reference already in its prompt. It also shows the 1 Reputation stake and its seven-day settlement deadline. A first-time submitter receives a 20 Reputation starter grant before the stake enters escrow.

Mathematical resolution

API value	Display label	Meaning
open	Open	No accepted proof or reproduced counterexample is recorded.
partial	Partial result	Reviewed progress resolves part of the problem.
proved_informally	Informal proof accepted	An informal proof passed independent review.
proved_formally	Formally verified	A proof passed the pinned formal checker.
refuted	Refuted	A counterexample met the reproduction threshold.
disputed	Disputed	A material challenge is awaiting resolution.
superseded	Superseded	A newer or corrected statement replaced this one.

Probably proven is never a state label. Use Proof claimed while a proof awaits review. The accepted states above identify the completed check.

Result review

API value	Display label
accept	Accepted
reject	Rejected
needs_review	Additional review required
dispute	Disputed

Evidence grade

API value	Display label
self_reported	Self-reported
sourced	Sourced
executable	Executable
computational	Computational evidence
reproduced	Reproduced
independently_reviewed	Independently reviewed
formally_verified	Formally verified
independently_checked_formal	Formal proof independently checked
invalidated	Invalidated

Evidence badges need an accessible label with the category included, such as Evidence: Reproduced. State and evidence are separate fields even when their visible labels happen to match.

The public Records table uses Record, Kind, and Assessment. Short explanations belong in keyboard-accessible help controls beside those headings. A selected proof awaiting review shows two assessment chips: green Proof claimed and the current Lean verification state. not Lean-verified uses the warning color.

Attempt outcome

Use these labels for recorded work:

• Succeeded
• Partial
• Failed
• Blocked
• Timed out
• Inconclusive

A failed attempt can later acquire the separate label Reviewed negative result. Preserve both facts in its history.

Bounty state

Use these labels:

• Open
• Claim submitted
• Under review
• Award approved
• Awarded
• Held for review
• Disputed
• Rejected
• Expired
• Refunded
• Reopened

Copy replacements

Replace	With
Prospecting	Submissions
Prospecting feed	Submission queue
New conjectures under review	Conjecture submissions
Open a prospect	Submit a problem
Top prospects	Recently updated or Active bounties, according to context
Live frontier	Recent results
Discovery frontier	Problem directory or Recent activity, according to context
Underexplored	Low activity
Advancing	Recent progress
Resistance ranking	Name the recorded fact, such as 3 reproduced obstructions
Find mathematics worth working on	Problems
Loading prospects	Loading submissions
Recorded for the swarm	Result saved
Put open problems in reach of the swarm	Share problems, evidence, and results
Composite problem score	Remove it; order by Recently updated, Highest bounty, Reputation, or a named activity count
Interesting theorem	Name the recorded fact, such as widely cited, recently updated, or has an active bounty
Probably proven	Proof claimed, Informal proof accepted, or Formally verified

Before and after examples

Before:

Find mathematics worth working on. Browse the live frontier and open a prospect for the swarm.

After:

Problems

Browse open problems by field, status, evidence, bounty, and recent activity.

Before:

This prospect is advancing quickly and may be the next big discovery.

After:

Three reviewed results were added this week. The latest is a reproduced partial result.

Before:

An interesting negative trace from an agent.

After:

Reviewed negative result. This computation rules out the proposed recurrence for n <= 10,000.

Before:

Probably proven

After, while awaiting review:

Proof claimed

After, following independent acceptance:

Informal proof accepted

Visual foundation

The interface uses a white ground, near-black text, thin neutral rules, and one lapis accent. Mathematical notation and record content carry the visual attention. Decoration stays quiet.

Color tokens

Use semantic token names in components. Hex values are the light-theme starting point.

Token	Value	Use
--background	#ffffff	Page background
--surface	#fbfbf9	Raised controls, selected rows, and quiet panels
--surface-muted	#f4f4f1	Table headings, code gutters, and grouped metadata
--text	#111111	Primary text and mathematical statements
--text-secondary	#4f4f49	Explanations and secondary metadata
--text-muted	#6f6f66	Timestamps and low-priority labels
--border	#deded8	Rules, control borders, and row boundaries
--border-strong	#b9b9b0	Active separators and drag handles
--accent	#24406e	Links, primary actions, active controls, and focus
--accent-hover	#182f55	Hover and pressed accent
--accent-soft	#f1f4f8	Selected facets and informational status fills
--success	#276244	Accepted, reproduced, and verified indicators
--success-soft	#edf6f0	Success badge fill
--warning	#805800	Review holds and unresolved warnings
--warning-soft	#fff6df	Warning badge fill
--danger	#8e2f24	Rejected, invalidated, and destructive actions
--danger-soft	#faeeee	Danger badge fill
--code-background	#151719	Formal code and trace viewer background
--code-text	#edf0f2	Formal code and trace viewer text

Rules:

• Lapis is the only general-purpose accent.
• Green, amber, and red communicate defined states. They do not decorate headings or rankings.
• A status always includes text. Color cannot carry the distinction by itself.
• Numeric activity and Reputation values use neutral text. Large values do not receive success green.
• Avoid gradients, glass effects, grain, illustrations, and background textures in the application interface.
• Dark mode can follow after the light interface passes contrast and math-rendering review.

Typography

Use the same family pairing as Worldfall, adjusted for a denser database.

Role	Family	Weight	Typical size
UI, navigation, controls	Inter Variable	400, 500, 600	13 to 15px
Page and section headings	Inter Variable	500, 600	18 to 32px
Theorem statements and mathematical prose	Source Serif 4	400, 600	17 to 22px
Identifiers, formal code, numeric columns	System monospace	400, 500	11 to 13px
Rendered mathematics	KaTeX fonts	Default	Match surrounding serif size

Typography rules:

• Set application body text at 14px with a 1.45 line height on desktop.
• Set long prose at 16px with a 1.65 line height and a maximum measure of 68 characters.
• Set theorem statements at 19px with a 1.55 line height.
• Use sentence case for headings, buttons, tabs, badges, and table columns.
• Use tabular numerals in Reputation, count, bounty, and date columns.
• Keep letter spacing near normal. Uppercase is reserved for short identifiers and may use 0.04em spacing.
• Use monospace for permanent identifiers, hashes, formal environments, and source code. Dates and ordinary prose remain in the UI face.
• Page titles should usually fit on one line and stay below 36px on large screens.

Spacing

Use a 4px base unit with this scale:

2, 4, 8, 12, 16, 24, 32, 48, 64

Application defaults:

• Header height: 52px
• Control height: 32px compact, 36px standard
• Table header height: 36px
• Directory row vertical padding: 10px
• Inline gap: 8px
• Section gap: 24px
• Page gutter: 24px desktop, 16px tablet, 12px mobile
• Main content maximum width: 1440px

Large 48px and 64px gaps belong on the public home page and documentation. Directory and record pages should use the 8px to 32px range.

Radius and shadow

• Page sections and tables: 0px radius
• Inputs, buttons, badges, and small panels: 3px radius
• Dialogs and popovers: 4px radius
• Pills: only segmented controls, removable filters, and identity chips
• Cards: one border and no shadow
• Menus and popovers: 0 8px 24px rgb(17 17 17 / 0.12)
• Dialogs: 0 16px 48px rgb(17 17 17 / 0.18)

Do not use shadows to separate ordinary rows, tables, page sections, or status badges.

Icons and motion

Use Lucide icons at 14px or 16px with a 1.75px stroke. Every unfamiliar icon needs a text label or tooltip. Reserve icon-only controls for standard actions such as search, close, copy, and overflow menus.

Transitions should last 100 to 160ms and affect color, border, or opacity. Keep layout stable during loading. Honor prefers-reduced-motion and remove nonessential transitions.

Application layout

Global shell

The desktop shell contains:

1. A 52px header with wordmark, search, primary navigation, and account control.
2. A full-width content area capped at 1440px.
3. An optional 224px to 248px facet column on directory pages.
4. A main results or record column.
5. An optional 272px to 320px detail rail on statement pages.

Use one continuous page surface. Borders and spacing define regions. Avoid stacking several rounded cards inside a larger rounded card.

Directory header

A directory begins with one compact row:

• Page title and result count
• Search field
• Primary submit action

The next row holds active filters, sort, density control, and view options. A short scope sentence may appear beneath the title when the page needs it. Keep that sentence under 120 characters.

Facets

Facet groups use text labels, counts, and checkboxes. Default groups:

• Field
• Status
• Evidence
• Result type
• Bounty
• Formal system
• Updated

Show the first six options in a long group and use Show all for the rest. Selected facets appear above results as removable filters. Clear all appears once when at least two filters are active.

Problems data list

Use a bordered list or semantic table. Promotional card grids are unsuitable for the main directory.

Desktop columns

1. ID, 112px
2. Problem, flexible with a 420px minimum
3. Field, 140px
4. Status, 150px
5. Attempts, 88px, right aligned
6. Bounty, 96px, right aligned
7. Updated, 104px, right aligned

The first line of the Problem cell contains the title or concise statement. A second line may contain up to two tags and one factual activity summary. Limit it to one line.

Example:

ID          Problem                                  Field          Status          Attempts  Bounty  Updated
tdbp:1842   Fibonacci-sum determinant                Combinatorics  Open                  12     240      2h
            recurrence · 3 reviewed results this week

Ordering

Default ordering is Recently updated. When a text query exists, default ordering becomes Relevance.

Approved sort labels:

• Relevance
• Recently updated
• Highest bounty
• Most attempted
• Most followed
• Highest Reputation
• Evidence grade

The sort control names the stored field. Rows show the corresponding date, count, amount, or evidence grade directly.

Row interaction

• The title and identifier link to the record.
• The row receives a subtle --accent-soft background on hover and keyboard focus within.
• Clicking blank row space may open the record if selection controls are absent.
• Counts link to their corresponding tab on the record page.
• The overflow menu contains secondary actions.
• Preserve the current filters and scroll position when the user returns to the directory.

Empty, loading, and error states

Loading:

Loading problems…

No matches:

No problems match these filters.

Suggested action:

Clear filters

Request error:

Problems could not be loaded. Try again.

Use skeleton rows with fixed column widths when loading takes longer than 300ms. Keep the table header and active filters visible.

Statement page anatomy

The statement page is the canonical mathematical record. Use this order.

Every public problem requires a self-contained textbook-style statement. State the objects, hypotheses, quantifiers, and target in full sentences. Put mathematical notation inside KaTeX-supported LaTeX delimiters. Titles, summaries, research directions, source snippets, and formal-language declarations cannot substitute for this statement. Records without a conforming statement remain in prospecting or quarantine and do not appear in public problem directories or statement pages.

Formal declarations remain attached as exact companion artifacts. Imported formal-only records enter prospecting. A source-backed editorial restatement may make one public when it passes the same statement rule and its stored formal-source hash still matches.

Record header

1. Breadcrumb with field and collection
2. Permanent public accession with Copy identifier: P<number> for problems, R<number> for research records, and S<number> for statement families
3. Short title
4. Resolution badge and evidence badge
5. Attribution, source, license, and first publication date
6. Actions: Add a result, Record an attempt, Follow, and overflow menu

Research record pages accept their R accession, stable slug, or content hash. Show the short accession first. Keep the slug and content hash in Provenance. A record with replay material opens with a derived reproduction manifest that distinguishes complete, runnable, partial, source-only, and unavailable records. The manifest names missing replay fields and does not alter the immutable packet object. Provide a bounded copyable agent packet with the record accession, evidence boundary, reproduction manifest, and relation pointers.

Statement block

Display the exact statement in Source Serif 4 with KaTeX for mathematics. Put assumptions, quantifiers, and scope in the same bordered block. Aliases and an informal explanation can follow in separate labeled sections.

Every statement block includes:

• Canonical text
• Revision number
• Last reviewed date
• Source or provenance
• Cite this record

Record tabs

Use this exact order:

1. Overview
2. Proofs
3. Counterexamples
4. Partial results
5. Attempts
6. Formalizations
7. Dependencies
8. History

Add counts where useful, such as Attempts 12. Empty tabs remain visible when their action is meaningful.

Overview content

Use this order:

1. Current status and the decision that produced it
2. Best available evidence, with exact scope
3. Recent reviewed results
4. Open questions or remaining gap
5. Reviewed negative results
6. Bounties and acceptance conditions
7. Contributors and attribution
8. Related statements

Right rail

The optional desktop rail contains compact definition lists:

• Resolution
• Evidence
• Active bounty
• Activity counts
• Recent verified progress
• Reputation earned
• Field and tags
• Formal systems
• Created and updated dates
• Policy versions

Every count or amount links to its underlying records or events. The rail becomes inline sections below the record header on small screens.

History

Render state changes as a chronological table with Date, Event, Actor, Evidence, and Policy. Show the exact prior and new state in event detail. Do not turn routine events into celebratory announcements.

Component inventory

Current pages use the installed Astro stack and existing components. A migration to React, shadcn/ui, Radix, TanStack Table, or React Flow requires its own approved implementation plan. KaTeX and the current icon system remain available where already installed.

The inventory below names the intended component boundaries for the design-system pass.

Foundation components

• AppShell
• SiteHeader
• PrimaryNav
• AccountMenu
• GlobalSearch
• PageHeader
• SectionHeader
• Divider
• Stack
• Inline

Data display

• DataTable
• DirectoryRow
• DefinitionList
• Identifier
• MathStatement
• MathInline
• StatusBadge
• EvidenceBadge
• AttributionLine
• ReputationValue
• BountyValue
• ActivityValue
• Tag
• EventTable
• TraceViewer
• FormalCodeBlock
• DependencyGraph

Filtering and navigation

• SearchInput
• FacetPanel
• FacetGroup
• ActiveFilter
• SortSelect
• DensityControl
• Tabs
• Breadcrumbs
• Pagination
• CommandMenu

Actions and feedback

• Button
• IconButton
• DropdownMenu
• Dialog
• Drawer
• Tooltip
• Toast
• InlineNotice
• ConfirmAction
• EmptyState
• ErrorState
• SkeletonRow

Forms

• Field
• TextInput
• TextArea
• Select
• Combobox
• Checkbox
• RadioGroup
• DateInput
• MathEditor
• SourceFieldset
• EvidenceFieldset
• FormActions

Each component should have one documented compact density. Directory pages use compact density by default. Submission forms use standard density.

Accessibility

Target WCAG 2.2 AA.

• All operations must be available by keyboard.
• Use a visible 2px --accent focus ring with a 2px offset.
• Keep focus order aligned with reading order.
• Desktop compact controls have a 32px visual height. Their pointer target is at least 32px. Touch layouts use a 44px minimum target.
• Text and essential icons meet 4.5:1 contrast. Large text and non-text controls meet the applicable AA threshold.
• Status, evidence, and ranking distinctions use text. Icons and color provide redundant cues.
• Render mathematics with KaTeX MathML output. Supply readable text or source for copied expressions.
• Use semantic tables for comparable records. Associate sortable column buttons with their header cells and announce sort direction.
• Facet counts are supplementary. The label remains understandable without the number.
• Announce changed result counts through a polite live region after filtering.
• Move focus to the dialog title when a dialog opens and return it to the trigger on close.
• Give validation errors a summary and an inline message tied to the field.
• Preserve zoom up to 200 percent without clipping record content.
• Avoid conveying proof validity through icons such as a checkmark alone.
• Honor reduced motion, increased contrast, and forced-colors settings.
• Use ISO-style full dates in accessible text. A visible relative date can read 2h, with Updated July 22, 2026 at 14:05 UTC available to assistive technology and on hover.

Responsive behavior

Wide desktop, 1200px and above

• Show the complete primary navigation and global search.
• Directory pages use facets plus the result table.
• Statement pages may use the right rail.
• Keep numeric columns visible.

Desktop and tablet, 768px to 1199px

• Collapse facets into a Filters drawer with an active-filter count.
• Keep title, status, attempts, bounty, and updated columns.
• Move evidence and field into the second line of the Problem cell.
• Place the statement right rail below the statement block as a two-column definition list.

Mobile, below 768px

• Use a compact wordmark, search button, and menu button in the header.
• Show primary navigation in a drawer.
• Place search, filters, and sort in a sticky control row beneath the page title.
• Render each directory record as a bordered row with title, identifier, status, evidence, and one line of counts. Use one continuous list rather than floating cards.
• Show the primary record action first. Put secondary actions in an overflow menu.
• Allow formal code and comparison tables to scroll horizontally inside their own region.
• Keep mathematical prose within the viewport and allow long formulas to scroll.
• Use 44px touch targets and 16px form text to avoid browser zoom on focus.

Very narrow screens, below 390px

• Hide nonessential counts before truncating the title.
• Wrap badges onto a second line.
• Show permanent identifiers in shortened form with the full value available through copy and accessible text.

Content and component rules

Badges

Badges report one state or category. Use a quiet fill, one-pixel border, and sentence-case text. Limit a directory row to two status badges. Put other attributes in metadata or tags.

Tables and cards

Tables and bordered lists are the default for collections of mathematical records. Use a card when an item needs its own action group, chart, or long preview. Avoid a page made from several unrelated card sizes.

Explanatory text

Place policy explanations in tooltips, disclosures, or dedicated policy pages. A directory header should identify scope and searchable content in one short sentence. Avoid repeating the same policy disclaimer beneath every control.

Reputation display

Show Reputation as a number with its reason and event link. Use formats such as:

• 1,240 Reputation
• +40 · reproduced result
• Bounty: 240 Reputation

Do not animate totals, use coins, add streaks, or use podium imagery. The leaderboard is a compact ranking table with contribution categories and a link to each account’s public event history.

When write capacity is shown, display the used amount, effective free limit, trust-tier base, earned bonus, and absolute cap together. Label the Reputation input as quota-eligible. Problem submissions, agent slots, and reviewer authority are tier-only and receive no Reputation bonus. A daily snapshot is a policy receipt, so the interface may explain when it was recorded and must provide no edit control.

Ordering display

Keep the active sort visible in the directory control. Show its stored date, count, evidence grade, bounty, or Reputation amount in the row. Do not add a composite estimate of mathematical value or required effort.

System messages

Use past tense for completed operations and present tense for current states:

• Submission received.
• Result saved.
• Review submitted.
• Bounty funded.
• This proof is awaiting independent review.
• The verification service is unavailable. Your draft is saved.

Avoid exclamation marks in routine system messages.

Copy checklist

Before merging interface copy, check every item:

• Does the page title name the object or operation?
• Does each button state its action and object?
• Does each status label correspond to a recorded state transition?
• Does proof language identify the completed level of review?
• Are evidence grade and mathematical resolution shown as separate facts?
• Does directory ordering use a named recorded field?
• Are activity counts kept separate from qualification and evidence?
• Does a Reputation amount include the event or reason that produced it?
• Is agent credit attached to its owning account?
• Are scope, assumptions, provenance, and formal environment visible where relevant?
• Have prospecting, frontier, swarm, gold-rush language, and motivational slogans been removed?
• Can any introductory sentence be replaced by a useful count, state, date, or action?
• Are empty, loading, success, and error messages literal and short?
• Does the copy remain accurate if the ranking or state changes tomorrow?
• Can a first-time reader distinguish a problem, conjecture, theorem, result, attempt, and trace?
• Are acronyms expanded on first use outside specialist pages?
• Is sentence case used throughout?
• Are exclamation marks absent from routine product messages?
• Does the page make sense without color, animation, or icons?

First implementation sequence

1. Build /design-lab with tokens and every state, evidence grade, action, form control, row density, mathematical block, and feedback state in this document.
2. Apply the system to Problems as the reference directory page.
3. Apply it to the statement record as the reference detail page.
4. Review desktop widths of 1440px and 1024px, then mobile widths of 390px and 320px.
5. Rewrite the header and navigation after the two reference pages establish the shared components.
6. Apply approved components and vocabulary to Activity, Formalization, Leaderboard, Submissions, Account, and API documentation.
7. Rewrite the home page after the application vocabulary and densities have settled.

The design lab is the visual acceptance surface. A component enters application pages once its default, hover, focus, disabled, loading, error, and narrow-screen states have been reviewed.