Page Type View

What kind of page does this route need to be?

Page type names the job. Section path names the terrain.

Naming leads structure. Use Naming Standards before this page when the folder, route, filename, business category, skill name, generated projection, or canonical term is not already settled. Return here after the name class and route are clear to choose the page job.

This page connects to the Tight Five through Purpose, Principles, Platform, Perspective, and Performance.

Type Catalogue

Every page has one job. Choose the job before writing the body.

• hub — orients a section and routes the reader. It does not teach. Use for top-level and section-level front doors such as /playbook/index.mdx, /playbook/wiki/wiki-index.mdx, and topic folder indexes.
• concept — explains one reusable idea. Use for models, standards, principles, and definitions that need a durable home.
• playbook — guides repeatable action. Use when the reader needs steps, outputs, checks, and failure modes.
• domain-map — maps a territory. Use for industries, domains, ecosystems, value chains, forces, players, and opportunity surfaces.
• evidence — preserves source-backed claims. Use when confidence, source trail, and implication matter more than teaching.
• glossary — clarifies language. Use when aliases, canonical terms, and contrast need to be explicit.
• decision-record — records a public architectural decision. Use when the decision, context, and consequences should remain visible.

Job-to-be-Done and Impact Structure

A page type is the relationship a page activates with its reader — and the page is the pipe. Match the structure to the one decision the reader is making.

Pick the job first. The structure follows. Each skeleton below is ordered: write it in that order and the page lands.

hub — orient and route

• Reader's job: "Route me to the right child fast. Don't teach me."
• Impact structure: one-line section purpose → choice logic above the fold → links grouped by job, each with scent → deep theory pushed to children.
• Lever: lands when the reader picks a path in five seconds; fails the moment it teaches.

concept — explain one reusable idea

• Reader's job: "I half-understand this idea. Give me one durable explanation I can reuse."
• Impact structure: name the idea in one line → the core move, compressed to its essence → why it matters and what it replaces. Then: how to apply it → where it breaks → the question that opens the next loop.
• Lever: lands when the reader can restate the idea in their own words; fails when it lists facts instead of teaching one model.

playbook — guide repeatable action

• Reader's job: "I need to do this reliably. Give me steps, outputs, and checks."
• Impact structure: the outcome it produces → preconditions and inputs → ordered steps, each with its output → checks and gates → failure modes → proof of done.
• Lever: lands when a new operator reaches the same output unaided; fails when it explains theory instead of driving action.

domain-map — map a territory

• Reader's job: "I'm new here and must choose where to act. Show me the terrain first."
• Impact structure: the territory boundary → the axes that organize it (players, platform, process, performance). Then: the choice logic → routes into deeper pages → where the gap is.
• Lever: lands when the reader leaves with a shortlist and a next route; fails when it teaches one node instead of mapping the field.

evidence — preserve source-backed claims

• Reader's job: "This claim must be trusted. Give me the source, the confidence, the implication."
• Impact structure: the claim stated plainly → source, date, and confidence → what it implies for action → contradicting evidence and limits → review trigger.
• Lever: lands when every claim traces to a source and the confidence is explicit; fails when assertions float without provenance.

glossary — clarify language

• Reader's job: "This term is ambiguous. Give me the canonical meaning and the contrasts."
• Impact structure: canonical term → one-line definition → aliases and what it is NOT → contrast with neighbors → usage note or example.
• Lever: lands when two readers use the term the same way; fails when it defines in a vacuum.

decision-record — record a public decision

• Reader's job: "This decision shapes future work. Record the reasoning, not only the result."
• Impact structure: the decision in one line → context and forces at the time → options considered. Then: the call and its rationale → consequences → review or kill signal.
• Lever: lands when a future reader understands why, not what; fails when it keeps the outcome but loses the reasoning.

Template Contract

Page type is stored in YAML frontmatter. Template pattern is the shape the page must follow.

In frontmatter, type means page type: the job this page performs for the reader and for agents. This follows the same portable idea as the Open Knowledge Format mapping, but the local contract is stricter: type must match one of the page jobs below, and template must match that type on new pages and material rewrites.

type: concept
template: concept-explainer-template
template_url: /playbook/standards/templates/concept-explainer-template

Use this mapping when creating, rewriting, or reviewing a /playbook page:

template is the stable slug. template_url is the route to the concrete template page. New pages and material rewrites should include both.

Page type	Template pattern	Use when the page must...
hub	hub-index-template	Route a reader through a section without becoming the lesson.
concept	concept-explainer-template	Explain one reusable idea, model, principle, or definition.
playbook	playbook-method-template	Guide repeatable action with steps, outputs, and checks.
domain-map	domain-map-template	Map a territory, options, actors, forces, or opportunity field.
evidence	evidence-brief-template	Preserve source-backed claims, confidence, and implication.
glossary	glossary-entry-template	Clarify terms, aliases, contrasts, and usage notes.
decision-record	decision-record-template	Record a decision, context, consequences, and review signal.

kb-content-patterns checks that a touched page's YAML type matches its body and that new pages or material rewrites declare the governing template and template_url.

Index Patterns

An index.md or index.mdx is not a type by itself. It is a front-door pattern applied to one of the page types above.

The page type answers "what job does this page perform?" The index pattern answers "how does this route help the reader choose?" Do not create a new page type just because a page is named index.

• Hub index — route a section. Applies to broad folders such as /playbook/, /playbook/standards/, /playbook/ai/, and /playbook/playbooks/.
• Domain-map index — help the reader choose inside a territory. Applies to folders such as /playbook/industries/, /playbook/business/, and domain-specific folders with players, platforms, process, and performance pages.
• Concept index — teach the central model for a folder, then route to deeper children. Applies when the folder is organized around one reusable idea rather than a navigation hub.
• Template index — help the editor choose the right template or standard. Applies to /playbook/standards/templates/ and similar operating-reference folders.
• Projection index — render a generated map from frontmatter or data. Applies to /playbook/wiki/wiki-index, /playbook/wiki/domain-matrix, and this page. The generated projection is a map, not hand-authored canon.

All index pages follow the Index Page Standard: route before teaching, show the choice logic above the fold, add scent to links, and move deep theory into child pages.

Where Applied

Use this routing table before rewriting an index.

Route shape	Page type	Index pattern	First-screen job
/playbook/index.mdx	hub	Hub index	Choose the main wiki start path
/playbook/<section>/index.*	hub	Hub index	Choose the right child page in a section
/playbook/applications/index.mdx	hub	Hub index	Choose the software-selection job first
/playbook/applications/*/index.*	domain-map	Domain-map index	Choose functions, categories, or vertical patterns
/playbook/applications/select-tech/	playbook	Method page	Run evidence gates before selecting a tool
/playbook/applications/build-or-buy/	playbook	Method page	Decide rent, bridge, own, or defer
/playbook/industries/index.mdx	domain-map	Domain-map index	Choose an industry shortlist before theory
/playbook/<domain>/<domain>-*/index.*	domain-map	Domain-map index	Choose by players, platform, process, or KPI
/playbook/standards/templates/index.*	hub	Template index	Choose the right reusable writing/build shape
/playbook/wiki/wiki-index.mdx	hub	Projection index	Read the generated public wiki spine
/playbook/wiki/domain-matrix.mdx	domain-map	Projection index	Read cross-domain intersections
/playbook/wiki/page-types.mdx	concept	Projection index	Choose the page job and governing pattern

If the route is an index but the first screen does not help the reader choose, rewrite the page or move the teaching into a child page.

When the route, filename, folder name, durable category, or placement axis is the open question, use Naming Standards. When the page job or index pattern is the open question, use this page.

Quality Bar

Page type is not only information architecture. It is the operating standard for what a page must make easy to read, trust, and act on.

Every reviewed page must pass five checks before visual taste enters the conversation:

• Comprehension: the first screen names one claim, one reader, and one next action.
• Legibility: body text and labels meet 4.5:1 contrast; large headings meet 3:1. Body text stays at 16px or larger; compact functional labels stay at 14px or above.
• Focus: each section does one job. If a page asks the reader to hold more than five models at once, split, collapse, or route.
• Integrity: links, buttons, dropdowns, chips, code, and raw endpoints say what they are before the reader clicks.
• Proof: a reviewer can name the measurement used: DOM contrast check, keyboard pass, mobile viewport pass, link target pass, or reader action pass.

Words are interface. A label that needs decoding is a failed control. A page that teaches machine-readable trust cannot hide its own keys, code tokens, or status labels in low contrast.

Surface Patterns

Story surfaces and reference surfaces share the same quality bar, but they fail in different ways.

Surface pattern	Page job	Must pass	Common failure
Story page	Persuade the reader through a sequence	One thesis, one proof path, one primary action per section, jargon defined before use	Seven mental models compete on one screen
Operating-model page	Explain how actors, loops, and contracts work	Actor table, loop steps, trust model, capability state, machine contract links, visible consequence	The model is sequenced well but key rows, chips, or badges are unreadable
Reference page	Let the reader look up stable language	Searchable terms, readable code tokens, consistent token styling, no color-only meaning	The page teaches vocabulary while syntax tokens have the weakest contrast
Symbol or notation page	Decode compressed language	Every symbol has text, every chip is legible, every blank placeholder has an intentional empty-state treatment	Pills or chips render white-on-white, so public standards and protocol names disappear
Raw endpoint	Serve machines first	Human-facing link copy says "raw JSON" or routes through an explanation page	A reader clicks a trust-contract card and lands in machine JSON with no context
Dense grid or table	Compare many items quickly	Stable columns, no mid-word wrapping in labels, horizontal scroll for code or long identifiers	Tokens break mid-word and the page looks imprecise while claiming machine-readable precision

Use the strongest working sibling as the local baseline. When two pages in one family look like different products, the weaker page must inherit the stronger one's type scale, contrast tokens, focus treatment, and interaction states. Do this before adding new decoration.

Review Checklist

Run this checklist on any src/pages story surface and on any /playbook page with rendered components, tables, code chips, or route cards. Treat it as the page-type version of the ux-audit-interface loop: Rendering, Visual, Responsive, Interaction.

• Contrast: sample computed text color against the actual composited background. Pass body, labels, chips, code tokens, and badges at at least 4.5:1 unless the text is large enough for the 3:1 heading threshold.
• Type size: keep body copy at 16px or larger. Keep meaningful labels, statuses, and use cases at 14px or larger. Reserve sub-12px text for incidental marks only.
• Keyboard: tab through every link, button, dropdown, and skip link. Focus must be visible, menu state must be announced, and focus order must match reading order.
• Touch: interactive targets must be at least 24px square, with 44px expected for primary mobile controls.
• Wrapping: labels and step names must not break mid-word. Code, DIDs, filenames, slugs, and route paths scroll or wrap at safe separators, not inside tokens.
• Density: count the models the reader must hold. Five is the working limit for one page; beyond that, collapse secondary material or route to child pages.
• Jargon: define DDL, DML, x402, IntentTrace, funnel terms, and local metaphors at or before first use, or link directly to the definition.
• Actions: each section should make the next action obvious: read next, inspect contract, copy endpoint, compare role, or open the proof.
• Machine handoff: raw files such as agent.json must be labelled as raw machine contracts, or paired with a human explanation page.
• Mobile: check 375px width for hero tables, loop cards, capability grids, code blocks, dropdown navigation, and footer links.

For agent-facing playbook pages, the first pass is legibility, then keyboard focus, then information density. Contrast failures in identity tables, DDL tokens, DML chips, and status badges block the page because they hide the proof surface itself.

Projection

Which page types are most represented in the wiki — and where are the gaps?

hub

338 pages

• First PrinciplesSubject navigation for First Principles.
• Product DesignSubject navigation for Product Design.
• PrinciplesSubject navigation for Advertising Principles.
• PrinciplesSubject navigation for AI Principles.
• PrinciplesSubject navigation for Food Principles.
• PrinciplesSubject navigation for Industry of Things Principles.
• MeetingsSubject navigation for Meetings.
• PrinciplesSubject navigation for Real Estate Principles.
• PrinciplesSubject navigation for Telecom Principles.
• FlowsSubject navigation for The Seven Flows.
• BitcoinSubject navigation for Bitcoin.
• PrinciplesSubject navigation for Sales Principles.

concept

825 pages

• EventsReusable concept note for Event Calendar.
• Information ArchitectureThe rules that decide where knowledge-base content goes, how each folder is shaped, and — by job-to-be-done — what format and authoring action to use. Built for human readers and answer engines alike.
• The MatrixReusable concept note for Character vs Capability.
• ScoreboardReusable concept note for Country Scorecard.
• FlowReusable concept note for Flow.
• FlowReusable concept note for Go with The Flow.
• Industry AnalysisA compact model for reading industries by layers, data intensity, value chains, platform buckets, and convergence.
• Industry MetaA compact model for reading industries by layers, data intensity, value chains, platform buckets, and convergence.
• JestReusable concept note for Jest Best Practices.
• Matrix ThinkingReusable concept note for Matrix Thinking.
• PrimitivesReusable concept note for Primitives.
• PlatformReusable concept note for Sui Platform.

playbook

178 pages

• Intelligent HyperlinksFrom hyperlinks to smart contracts to agent protocols — the three generations of piping that turn thoughts into things
• Truth-SeekingRepeatable action guide for Truth-Seeking Protocol.
• Config ArchitectureRepeatable action guide for Agent-Agnostic Config.
• PerplexityRepeatable action guide for Perplexity.
• PerformanceRepeatable action guide for Advertising KPIs.
• CoachRepeatable action guide for Coach.
• MantraRepeatable action guide for Mantra.
• IntegrityRepeatable action guide for Value Integrity.
• Control SystemRepeatable action guide for Control System.
• QuarterRepeatable action guide for The Ideal Quarter.
• Audit a PageRepeatable action guide for How to Audit a Page.
• Self (Body, Mind, Spirit)Repeatable action guide for The Archipelago — Self.

domain-map

232 pages

• PrinciplesTerritory map for Agriculture Principles.
• PrinciplesTerritory map for AI Data Principles.
• PrinciplesTerritory map for Construction Principles.
• PrinciplesTerritory map for Education Principles.
• PrinciplesTerritory map for Legal Industry Principles.
• MemecoinsTerritory map for Memecoin Tokens.
• PrinciplesTerritory map for Payments Principles.
• PrinciplesTerritory map for Robotics Principles.
• PrinciplesTerritory map for Security Principles.
• PrinciplesTerritory map for Solar Principles.
• PerformanceThe KPIs that matter in space infrastructure — from launch economics to constellation operations
• PlatformThe ABCD technology stack for space infrastructure — AI, Blockchain, Crypto, and DePIN at orbital scale

evidence

26 pages

• TimeEvidence brief for Time.
• AI/LLM BenchmarksEvidence brief for AI/LLM Benchmarks.
• AlignmentEvidence brief for Alignment.
• Blockchain BenchmarksEvidence brief for Blockchain Benchmarks.
• CapitalAgency depends on capital. Capital has types. Goodwill compounds when money goes to zero.
• CommissioningEvidence brief for Commissioning.
• ContentEvidence brief for Content Metrics.
• CryptoEvidence brief for Crypto Investing Metrics.
• EconomicsEvidence brief for Economics KPIs.
• Engineering QualityEvidence brief for Engineering Quality.
• FoundationsEvidence brief for Foundations.
• GoodwillEvidence brief for Goodwill.

glossary

1 pages

• GlossaryPublic entry point for canonical Dreamineering language.

decision-record

1 pages

• AI-Native Business Function AnalysisAgent-facing flow note for explaining business functions and using AI to optimize performance toward customer-success outcomes.

The projection above is generated from page frontmatter — a derived map, never hand-authored truth.

Questions

• Does the page job match the reader's next decision?
• Does the first screen make the route, claim, and next action obvious?
• Does the rendered page pass contrast, keyboard, wrapping, and mobile checks before visual taste enters the conversation?

Preflight Choice

Before a /playbook edit, choose and record:

• change_class: maintenance, content, new-page, or rewrite
• route: the public /playbook/... destination
• page_type: the job the page performs
• template: the shape that governs the edit
• language_expected: whether DDL/DML updates are likely

New pages and material rewrites must declare page_type and template before editing. Maintenance edits still need a preflight reason so the close record can distinguish a formatting fix from a content decision.

Index pages are decision surfaces. They route before they teach. Use the Index Page Standard before rewriting any /playbook/**/index.* page.

Hub pages orient and route. They do not teach. Use the Hub Index Template for the full migration process.

Enforcement

Touched /playbook pages now close through two local gates:

• wiki-flow-guard.mjs blocks edits that skipped Map-First preflight or close receipts.
• playbook-content-check.mjs --strict blocks touched playbook pages whose type, template shape, or inner/outer boundary fails.

Legacy untouched pages remain backlog. Once a page is touched, it must carry frontmatter type and match its page job before Stop, commit, pre-push, or npm run playbook:quality can pass. Emergency bypasses use the auditable WIKI_FLOW_OVERRIDE=1 receipt path.

Failure Modes

• Type drift: The frontmatter says hub, but the body teaches. Change the type or move teaching into child pages.
• Template drift: The page records a template in preflight but closes without the sections that template requires.
• Advisory drift: The post-edit warning fires, but no blocking gate catches the same failure at commit time.

Story Surfaces

src/pages pages sell the Dream, frame the journey, and point toward reusable charts. They may carry the narrative spine, current offer, or product story. They should not become knowledge buckets.

/playbook pages teach reusable know-how. Community, games, systems, agency, AI, and crypto belong here when the reader can apply the pattern without knowing this repo.

Context

• Hub Index Template — enforced shape for orientation pages
• Index Page Standard — reusable rules for all /playbook index pages
• Documentation Writing Standard — writing shape for reusable know-how
• Wiki Schema — projection fields used by the docs map