# UnwindCode.ai Experience Evolution Audit

Source reference: https://www.anthropic.com/
Reviewed: 2026-06-18
Scope: site-wide experience direction for UnwindCode.ai.
Boundary: This is a principle translation, not a clone request. Anthropic's homepage is used to study storytelling, trust sequencing, information architecture, motion restraint, and attention management. UnwindCode.ai keeps its own identity: Organisms, not Apps; Infinity Mirror; Brain Cell Architecture; Visual Cortex; Research Organisms; Financial Organisms; and the operating philosophy of proof before authority.

Implementation packet: `assets/specs/unwindcode-experience-evolution-implementation-packet.json` converts this audit into a machine-readable build contract for route jobs, component contracts, motion contracts, React/Next migration boundaries, Framer and Three.js gates, design tokens, asset requirements, accessibility gates, mobile gates, SEO gates, performance budgets, rollout phases, and acceptance evidence.

## Executive Thesis

UnwindCode.ai should feel like a premium AI + Web3 architecture lab where intelligence is not announced as magic. It is inspected as an organism: signal enters, memory gives context, cells do bounded work, the immune system controls risk, and proof comes back before authority expands.

The site should move from impressive pages to a coherent public operating system. Every visual, animation, dashboard, map, status card, route, and interaction must answer three questions:

1. What real workflow, memory layer, research lane, deployment artifact, or capability does this represent?
2. What state is it in: Concept, Research, Prototype, Experimental, or Live?
3. What proof can the visitor inspect before trusting it?

## Non-Clone Boundary

Do not copy Anthropic's layout, brand hierarchy, color system, illustration language, card treatment, release taxonomy, or section rhythm. The useful pattern is deeper: the homepage reduces a complex technical organization into a calm sequence of mission, capability, trust, research, and action.

Unwind's translation must be more architectural and organism-native:

- Anthropic centers frontier AI safety and products; Unwind centers governed AI organisms with human approval boundaries.
- Anthropic uses institutional trust and research authority; Unwind uses public proof loops, transmissions, metadata, and architecture ledgers.
- Anthropic can speak as an AI lab with mature products; Unwind must mark product states honestly and label future capabilities before they are live.
- Anthropic's homepage can stay broad; Unwind needs conversion paths for builders, investors, users, subscribers, protocols, and collaborators.

## Current Source Snapshot

Reviewed source state on June 21, 2026:

- Hero thesis binds AI research and products to safety at the frontier.
- The featured research beat is "What 81,000 people want from AI."
- Latest releases still expose dated public memory in the same observed order: Expanding Project Glasswing (June 2, 2026), Claude Opus 4.8 (May 28, 2026), and Introducing The Anthropic Institute (March 11, 2026).
- Long-term well-being, safety resources, education, policy, product, model, platform, and company routes are discoverable from the same public surface.
- Product pathways include Claude, Claude Code, Claude Code for Enterprise, Claude Cowork, Claude Design, Claude Security, Claude Platform, Claude for Chrome, Claude for Slack, Claude for Microsoft 365, Skills, pricing, plans, download, and sales routes.
- Model routes include Mythos, Fable, Opus, Sonnet, and Haiku; solution, platform, marketplace, provider, resource, help/security, status, company, and policy routes sit in dense footer IA, while privacy choices expose analytics and marketing as explicit measurement choices.

Unwind rule: these observations are current research inputs, not permanent instructions. Future source-inspired recommendations must re-check the reference, record what changed, and route every adopted pattern to a Unwind proof surface. Stale source memory, copied section rhythm, copied visual treatment, affiliation claims, telemetry assumptions, or unverified product claims are rejected.

## UX Audit

### 01. Information Architecture

Why it works: The reference homepage makes the organization legible before it becomes detailed. A visitor can move from identity to products, research, responsibility, company context, and conversion without learning a new vocabulary at every step.

How UnwindCode can reinterpret it: Keep the public nav simple, but make each route carry a distinct proof job:

- Organisms: product identities and status.
- Architecture: how organisms think, remember, route, and stop.
- Proof: evidence, labels, tests, and authority gates.
- Transmissions: build records and research dispatches.
- Philosophy: operating doctrine and human boundary.
- Build With Us: conversion into a bounded first packet.

Implementation opportunities:

- Preserve the glass-bubble navigation as a persistent lab instrument rather than a flat website bar.
- On mobile, use a right-side drawer with readable rows, clear current route, visible Talk to Brain and Build With Us actions, Escape close, outside-click close, and body scroll lock.
- Add route-local status chips where visitors first encounter an organism: Concept, Research, Prototype, Experimental, Live.

### 02. Storytelling Flow

Why it works: The reference experience earns abstraction gradually. It does not begin with implementation detail; it starts with a clear institutional promise, then shows product and research proof.

How UnwindCode can reinterpret it: The homepage should progress from organism thesis to proof paths:

1. Hero: AI organisms built with proof.
2. Organism loop: signal, gateway, cortex, memory, cells, immune system, proof.
3. Product paths: Visual Cortex, Infinity Mirror, Financial Organisms, Brain Cell Architecture, Research Organisms.
4. Trust paths: architecture evidence, status labels, transmissions, Web3 simulation boundary.
5. Collaboration paths: builders, investors, users, subscribers, protocols, collaborators.

Implementation opportunities:

- Keep first-viewport copy plain enough that a non-technical visitor understands the promise.
- Move dense architecture language into inspectable maps and cards after the emotional hook.
- Use each CTA to route to a proof artifact, not a vague contact funnel.

### 03. Scroll Choreography

Why it works: The reference homepage uses scroll as staged attention rather than constant spectacle. The visitor receives one conceptual beat at a time.

How UnwindCode can reinterpret it: Scroll should behave like an organism run:

- Signal enters.
- Context is framed.
- Capability is selected.
- Risk boundary appears.
- Proof is returned.
- Next action is offered.

Implementation opportunities:

- Use section reveal only when it clarifies the story stage.
- Keep hash links stable and fixed-nav aware.
- Avoid scroll effects that hide content, create layout shift, or make proof feel theatrical instead of inspectable.

### 04. Motion Systems / Motion Architecture

Why it works: Motion in a premium AI lab should communicate control. It should make a state transition feel understandable, not merely futuristic.

Motion must communicate Intelligence, Learning, Memory, Reflection, Evolution, and Emergence while keeping meaning available in static text.

How UnwindCode can reinterpret it: Every animation should explain a system:

- Pulse means a signal moving through the organism.
- Orbit means a cell routed around a shared cortex.
- Reflection means a user signal being translated into a proof artifact.
- Lock means an authority boundary.
- Growth means a tested capability moving from proposal to integrated cell.

Implementation opportunities:

- CSS and SVG remain the default motion layer.
- Framer Motion is only for isolated React leaves after migration approval.
- GSAP is only for desktop chapter choreography with named cleanup and stop conditions.
- Three.js is optional, desktop-first, and reserved for true depth experiences like Infinity Mirror, never for ordinary decoration.
- Reduced-motion mode must keep all meaning in text and static layout.

### 05. Visual Hierarchy

Why it works: The reference homepage uses generous spacing, strong type, and quiet hierarchy so visitors can trust what they are reading.

How UnwindCode can reinterpret it: Use premium restraint with organism-specific moments:

- Hero scale for the central thesis only.
- Compact headings for cards, consoles, proof ledgers, and dashboards.
- Glass and glow should behave like instrumentation, not background decoration.
- Dense proof areas should be scannable and calm.

Implementation opportunities:

- Keep cards at tight radii unless an organism interface explicitly requires a portal/shell form.
- Avoid nested cards.
- Make maps and dashboards full-width bands or unframed tool surfaces, not decorative boxes inside boxes.
- Ensure every image or asset earns its place by improving comprehension, trust, navigation, or proof.

### 06. Typography System

Why it works: The reference homepage makes large claims readable and keeps supporting copy quiet. The hierarchy does not fight itself.

How UnwindCode can reinterpret it:

- Hero type names the offer: AI organisms built with proof.
- Section titles explain the visitor question.
- Labels name system states, proof types, and authority boundaries.
- Technical copy uses short lines and direct nouns.

Implementation opportunities:

- Do not scale font size with viewport width.
- Avoid negative letter spacing.
- Use monospace sparingly for ledgers, states, and protocol labels.
- On mobile, prioritize readable text over cinematic composition.

### 07. Navigation

Why it works: The reference keeps navigation calm and predictable. The visitor always knows where the institution begins and where action lives.

How UnwindCode can reinterpret it:

- Desktop navigation should feel like a transparent glass instrument sitting over the lab.
- Tablet and mobile navigation should become a right-side drawer so long labels remain readable.
- The drawer is not a full-screen takeover; it is a focused command surface.

Implementation opportunities:

- Preserve the glass-morph nav refraction layer.
- Keep active route and language toggle visible.
- Duplicate the primary CTA inside the drawer on compact layouts.
- Close on link selection, outside click, and Escape.

### 08. Attention Management

Why it works: The reference homepage does not ask visitors to parse every capability at once. It uses progressive disclosure.

How UnwindCode can reinterpret it:

- First-time users need the organism thesis.
- Builders need architecture and implementation contracts.
- Investors need proof, risk boundaries, and status labels.
- Users need the Infinity Mirror path and human boundary.
- Protocols need Financial Organisms and Web3 simulation posture.
- Collaborators need the Build With Us packet.

Implementation opportunities:

- Use visitor-path controls as routing instruments, not marketing decoration.
- Keep non-live states visible at the moment of desire.
- When a feature is a concept or research lane, say that directly before conversion.

### 09. Emotional Progression

Why it works: A good AI lab homepage creates confidence without overpromising. It makes the visitor feel that complex systems can be inspected.

How UnwindCode can reinterpret it:

1. Curiosity: what is an AI organism?
2. Recognition: this is more than an app.
3. Trust: boundaries and proof are visible.
4. Agency: I can choose the right path.
5. Invitation: I can build, invest, use, subscribe, or collaborate.

Implementation opportunities:

- Infinity Mirror owns the deepest emotional route.
- Proof owns relief and trust.
- Build With Us owns agency.
- Philosophy owns the human reason the architecture exists.

### 10. Performance Strategy

Why it works: A premium lab site feels fast and deliberate. Heavy motion should not block comprehension.

How UnwindCode can reinterpret it:

- Default surfaces use semantic HTML, CSS, and lightweight SVG.
- Canvas is bounded, aria-hidden, and progressive.
- WebGL waits for a clear product reason and a mobile fallback.
- Metadata and public specs remain crawlable.

Implementation opportunities:

- Keep critical routes dependency-light in the current Vite build.
- Lazy-load visual assets after the first viewport unless they are part of the hero.
- Avoid runtime-only proof. If a crawler, screen reader, or low-power device cannot inspect the claim, the claim is not durable.

## Design Research

### Extracted Principles

- Calm authority: trust comes from sequence, restraint, and plain language.
- Capability laddering: complex work becomes understandable when product, research, and responsibility are separated.
- Proof proximity: claims are stronger when evidence is near the claim.
- Clear institutional voice: the site should sound like a lab with a doctrine, not a SaaS brochure.
- Conversion through fit: different visitors need different first proof packets.

### Unwind-Specific Principles

- Organisms, not Apps: every route should teach continuity, memory, cells, immune boundaries, and proof.
- Intelligence as biology: loops, cells, cortex, memory, and growth are the native metaphors, but they must always point to architecture.
- Proof before authority: every future capability needs a visible evidence path before a claim of autonomy.
- Human boundary: filesystem writes, money, public posts, Web3 broadcast, diagnosis, identity inference, and hidden memory stay behind explicit approval.
- Manual honesty: if a workflow is currently manual, prototype, or research-only, the page must say so.

### Experience Evolution Concepts

Infinity, Reflection, Recursion, Neural Growth, Cognitive Evolution, Living Systems, Intelligence Organisms, and Digital biology are allowed only when they clarify a real Unwind system. Each concept must point to route architecture, proof return, memory, bounded cells, research loops, status labels, or authority gates. None of these metaphors can imply live autonomy, hidden memory, diagnosis, identity inference, financial authority, deployment authority, public posting, private data pulls, or Web3 broadcast.

### Implementation Packet Contract

The implementation packet exists so future agents do not reinterpret the audit loosely. It makes these items inspectable as data:

- Source reference and non-clone boundary.
- Preserved center of the UnwindCode.ai identity.
- Route jobs and required public surfaces.
- Backend-to-frontend reflection rules.
- Component contracts for navigation, status rails, authority gradients, conversation gateway, and motion ledger.
- Motion contracts with meaning, fallback, cleanup, stop condition, proof source, and authority boundary.
- First-class React architecture, Next.js structure, Framer Motion rules, Three.js opportunity gates, design tokens, asset requirements, accessibility gates, mobile strategy and gates, SEO/discovery gates, performance budgets, rollout phases, and acceptance evidence.

No item in the packet grants runtime authority. It is a build contract, not a migration, dependency install, deployment approval, telemetry system, policy engine, or autonomous controller.

## Information Architecture Improvements

Recommended public structure:

```text
/
  Hero: AI organisms built with proof
  Homepage Choreography Compass
  Organism Loop
  Visitor Pathway Map
  Trust Progression Rail
  Product Organisms
  Architecture Proof Runway
  Proof and Authority
  Authority Gradient
  Public Learning Loop
  Transmissions / Proof Library
  Subscribe / Conversation Gateway

/organisms/
  Organism Index
  Status Matrix
  Product Identity Constellation

/organisms/infinity-mirror/
  Human-facing reflection organism
  Prototype status
  Experience route

/organisms/visual-cortex/
  Creator intelligence path
  Production packet proof

/organisms/financial-organisms/
  Web3 simulation lane
  Unsigned packet forge
  Value-motion readiness ledger
  No-broadcast boundary

/organisms/brain-cell-architecture/
  Self-evolving capability architecture
  Sandbox and approval boundary
  Sandbox evidence board

/architecture/
  Stack model
  Request route
  Authority topology
  Memory continuity
  Node protocol and future runtime boundaries

/proof/
  Proof hero console
  Evidence ledger
  Authority gates
  Asset governance
  Status definitions

/transmissions/
  Public build records
  Transmissions hero console
  Social packets after approval

/philosophy/
  Philosophy hero console
  Operating doctrine
  Human authority

/build-with-us/
  Role-specific conversion for builders, investors, users, subscribers, protocols, and collaborators
  First packet protocol
```

## Backend-to-Frontend Reflection Matrix

State labels in this matrix are product truth, not decoration. Every frontend surface must name whether the reflected system is Concept, Research, Prototype, Experimental, Live, or a mixed local-proof surface before it asks for trust.

| Surface | Real System Reflected | State Label | Proof Source | Rule |
| --- | --- | --- | --- | --- |
| Hero Signal Field | Visitor intent moving through gateway, cortex, memory, proof, and approval boundary | Prototype | Semantic hero console, asset manifest, tests | Canvas stays aria-hidden and cannot carry critical text. |
| Organism Pulse Field | Governed organism loop | Prototype | SVG metadata, i18n copy, llms.txt | Motion means routing, not ambient decoration. |
| Homepage Route Atlas | Early wayfinding across build, use, verify, follow, and collaborate proof lanes | Local proof | Homepage route atlas, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The atlas is static public navigation only; it cannot personalize, infer intent, store hidden memory, execute, deploy, post, spend, open chat, subscribe, pull private data, or broadcast Web3. |
| Homepage Proof Broker | Visitor questions translated into organism path, first packet, proof route, and authority stop | Local proof | Homepage proof broker, homepage-proof-broker SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The broker is static public proof routing only; it cannot personalize, infer intent, open chat, subscribe, execute, deploy, post, spend, trigger outreach, pull private data, store hidden memory, connect wallets, sign transactions, custody assets, or broadcast Web3. |
| Glass Lab Nav Brain Gateway | Site-wide route recovery to the governed Brain gateway and collaboration intake, with compact drawer orientation receipt for Home, Brain, and Build recovery | Local proof | Shared nav markup, shared i18n shards, main.js drawer receipt and clone logic, style.css glass drawer, ai-services.json, asset manifest, tests | The nav routes attention only; it cannot open hidden chat on secondary pages, personalize, infer identity, submit data, store memory, execute, deploy, post, spend, pull private data, change statuses, or broadcast Web3. |
| Homepage Current Proof Dispatch | Early release proof across production checkpoint, route clarity, Brain receipt, website-awareness parity, and transmission social packet readiness | Local proof | Homepage proof dispatch, homepage-proof-dispatch-relay SVG, production checkpoint JSON, Brain response contract, Brain Awareness Checkpoint, transmissions archive, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The dispatch routes visitors to public proof only; it cannot personalize, infer intent, open chat, subscribe, execute, deploy, post, spend, trigger outreach, pull private data, store hidden memory, sign transactions, or broadcast Web3. |
| Homepage Web3 Trust Lock | First-scroll value-motion boundary across read-only context, unsigned packet, broadcast lock, and human custody | Local proof | Homepage Web3 trust lock, SVG asset, Financial Organisms proof anchors, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The trust lock makes Web3 safety inspectable; it cannot connect wallets, personalize, infer intent, custody assets, sign transactions, approve spend, broadcast Web3, execute, deploy, post, pull private data, or create financial advice. |
| Homepage Organism Routing Lattice | Visual plus semantic selector mapping one request through gateway, memory, cells, authority gate, and proof return | Local proof | Homepage routing lattice, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The lattice is text-first guidance with decorative SVG support; it cannot personalize, infer intent, store hidden memory, execute, deploy, post, spend, trigger outreach, pull private data, sign transactions, approve wallets, or broadcast Web3. |
| Homepage Organism Switchboard | Four primary organism paths compared by job, audience fit, first artifact, maturity state, proof route, safe first action, and blocked authority before product cards | Local proof | Homepage switchboard, organism-pathway-switchboard SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The switchboard is product-path guidance with decorative SVG support; it cannot personalize, infer intent, open chat, subscribe, execute, deploy, post, spend, trigger outreach, pull private data, install cells, connect wallets, sign transactions, or broadcast Web3. |
| Homepage Organism Proof Quartet | Visual Cortex, Infinity Mirror, Financial Organisms, and Brain Cell Architecture compared by status, first artifact, proof route, and authority stop before product cards | Local proof | Homepage proof quartet, organism-proof-quartet SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The quartet is static proof navigation with decorative SVG support; it cannot personalize, infer intent, open chat, subscribe, execute, deploy, post, spend, trigger outreach, pull private data, install cells, connect wallets, sign transactions, custody assets, move value, or broadcast Web3. |
| Homepage Organism Vocabulary Decoder | Gateway, Cortex, Memory, Cells, Immune System, and Proof Loop translated into plain meaning, inspection checkpoints, and blocked claims before product cards | Local proof | Homepage vocabulary decoder, organism-vocabulary-decoder SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The decoder is static public education with decorative SVG support; it cannot personalize, infer intent, store hidden memory, execute, deploy, post, spend, trigger outreach, pull private data, install cells, connect wallets, sign transactions, or broadcast Web3. |
| Homepage Search Intent Compass | AI agents, Web3 architecture, autonomous systems, cognitive agents, on-chain intelligence, AI organism design, immersive AI interfaces, and agentic software architecture routed into proof paths and blocked claims, with Web3 architecture landing custody-first | Local proof | Homepage search intent compass, homepage-search-intent-compass SVG, Web3 Custody Boundary Map, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The compass is static public guidance with decorative SVG support; it cannot personalize, infer intent, claim live autonomy, connect wallets, open wallet sessions, handle private keys, custody assets, move money, run hidden memory, deploy, post, execute work, pull private data, or broadcast Web3. |
| Organisms Hero Console | First-viewport ecosystem routing across Visual Cortex, Infinity Mirror, Financial Organisms, Brain Cell Architecture, Research Organisms, and shared proof dock | Local proof | Organisms hero console, organisms-hero-console SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console routes visitor attention to public organism paths and proof only; it cannot personalize, infer intent, execute, open chat, deploy, publish, spend, pull private data, install cells, connect wallets, sign transactions, broadcast Web3, or promote status. |
| Organism Translation Layer | Static app request translated into gateway signal, visible memory, replaceable cells, returned proof, and authority stop before lane selection | Local proof | Organism translation layer, organism-translation-layer SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The layer is static public education with native radio controls; it cannot execute, personalize, infer identity, deploy, post, spend, pull private data, install cells, connect wallets, or broadcast Web3. |
| Organism Product Pathway Console | Four flagship organisms mapped from incoming signal to organism loop, proof artifact, authority stop, and next route before identity selection | Local proof | Organism product pathway console, organism-product-pathway-console SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console is static product-path education with native radio controls; it cannot personalize, infer intent, execute, deploy, post, spend, pull private data, install cells, connect wallets, sign transactions, or broadcast Web3. |
| Organism Operating Theater | Flagship organism coordination mapped across input, specialist cells, proof return, and authority locks before identity selection | Local proof | Organism operating theater, organism-operating-theater SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The theater is static ecosystem education with native radio controls; it cannot personalize, infer intent, execute, open hidden chat, deploy, post, spend, pull private data, install cells, connect wallets, sign transactions, broadcast Web3, change status, or move authority across organisms. |
| Organism Relay Map | Cross-organism handoffs mapped from received signal to proof return and authority stop | Local proof | Organism relay map, organism-relay-map SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The relay is static ecosystem education with semantic ordered steps; it cannot execute, infer intent, track identity, publish, deploy, spend, pull private data, install cells, connect wallets, sign transactions, broadcast Web3, or move authority across organisms without proof and approval. |
| Organism Proof Dock | Organism lanes mapped to first artifact, proof route, authority boundary, and next inspection route | Local proof | Organism proof dock, organism-proof-dock SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The dock is static proof navigation with native radio controls; it cannot execute, publish, deploy, spend, connect wallets, sign transactions, broadcast Web3, store hidden memory, infer identity, personalize, pull private data, install cells, or trigger outreach. |
| Organism Authority Matrix | Flagship organism lanes compared by first safe action, proof route, and hard stop | Local proof | Organism authority matrix, organism-authority-matrix SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The matrix can compare safe first actions and proof routes; it cannot execute, publish, deploy, spend, pull private data, connect wallets, sign, broadcast Web3, install cells, infer identity, or trigger outreach. |
| Homepage Research Gate | Source provenance, non-clone translation, product-safe research routing, and authority stops before source-inspired interface changes | Local proof | Homepage research gate, Source Freshness Gate, Source Translation Ledger, Research Translation Ledger, Authority Gate, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate is static provenance and translation guidance only; it cannot imply affiliation, endorsement, copied design, hidden telemetry, personalization, identity inference, live source monitoring, status promotion, deployment, public posting, spend, private data pulls, or Web3 broadcast. |
| Homepage Source Adoption Matrix | Current source principles mapped into Unwind organism surfaces, proof routes, and blocked uses before long-scroll interpretation | Local proof | Homepage source adoption matrix, Research Gate, Authority Gate, Release Memory Ledger, Infinity Mirror route, Build With Us route, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The matrix is static source-translation evidence only; it cannot imply affiliation, endorsement, copied design, hidden telemetry, personalization, identity inference, live source monitoring, lead scoring, workflow execution, deployment, public posting, spend, private data pulls, or Web3 broadcast. |
| Homepage Emotional Proof Arc | Source-inspired emotional progression mapped to possibility, concern, recognition, relief, and agency with proof routes and stop conditions | Local proof | Homepage emotional proof arc, Hero pulse, Authority Gate, Organism Primer, System State Console, Brain receipt, Build With Us packet, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The arc is static public guidance only; it cannot profile emotions, personalize, infer identity, store hidden memory, run telemetry, diagnose visitors, execute, deploy, post, spend, pull private data, or broadcast Web3. |
| Homepage Motion Meaning Ledger | Motion language mapped to pulse, route, memory, reflection, and growth systems before choreography expands | Local proof | Homepage motion meaning ledger, System State Console, Route Atlas, Transmissions, Infinity Mirror, Brain Cell lifecycle, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger is static public guidance only; it cannot create telemetry, live monitoring claims, animated proof counters, personalization, intent inference, emotional profiling, hidden memory, source polling, automatic posting, deployment, self-installing cells, unreviewed code execution, private data pulls, spend, or Web3 broadcast. |
| Homepage Choreography Compass | Scroll attention as an inspectable organism run across signal, definition, architecture, state, public memory, and bounded invitation | Live | Homepage choreography compass, llms.txt, ai-services.json, implementation packet, tests | The compass is static anchor navigation only; no personalization, telemetry claim, scroll hijack, execution authority, public posting, deployment, spending, outreach, private data pull, or Web3 broadcast. |
| Homepage Human Signal Ledger | Mental room, build momentum, trust diligence, value safety, and public learning mapped to organism paths, proof returns, and authority stops | Live | Homepage human signal ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | Human signal is public translation, not profiling; the ledger cannot personalize, diagnose, infer identity, track emotion, execute, deploy, post, spend, pull private data, approve wallets, or broadcast Web3. |
| Homepage Signal-to-Proof Run Ledger | Gateway intake, memory/context fence, specialist cell routing, authority gate, proof return, and human handoff mapped as one bounded organism run | Live | Homepage signal-to-proof run ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The run ledger is static public guidance only; it cannot personalize, track identity, store hidden memory, execute, deploy, post, spend, approve wallets, pull private data, or broadcast Web3 transactions. |
| Homepage State Ladder | Concept, Research, Prototype, Experimental, and Live as inspectable maturity contracts before product selection | Live | Homepage state ladder, llms.txt, ai-services.json, implementation packet, tests | The ladder defines proof needed and authority blocked; it cannot poll telemetry, promote status, personalize, execute, deploy, post, spend, pull private data, or broadcast Web3 transactions. |
| Infinity Mirror Hero Console | First-viewport reflection path across signal, mirror, memory consent, artifact return, and human boundary | Local proof | Infinity Mirror hero console, route CSS, textless SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can explain the first safe reflection path; it cannot diagnose, infer identity, store hidden memory, make care decisions, trigger public action, deploy, post, spend, pull private data, connect wallets, sign transactions, or broadcast Web3. |
| Infinity Mirror Reflection Artifact Router | State, identity, decision, and support signals translated into first artifact, proof route, and authority lock | Local proof | Infinity Mirror artifact router, textless SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The router can clarify the first reviewable reflection artifact; it cannot diagnose, infer identity, store hidden memory, make care decisions, handle crisis support, publish, write files, deploy, spend, pull private data, connect wallets, sign transactions, broadcast Web3, or create external consequences. |
| Infinity Mirror Memory Consent Gate | Ephemeral, proposed, reviewed, and integrated memory states exposed before reflection uses continuity | Local proof | Infinity Mirror memory consent gate, memory consent SVG, Memory Recall Receipt, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate can explain memory consent and review states; it cannot store hidden memory, profile users, infer identity, diagnose, make care decisions, create irreversible identity models, trigger public action, deploy, post, spend, pull private data, or broadcast Web3. |
| Infinity Mirror Experience | Reflection organism, signal routing, proof return, authority gradient | Prototype | Experience route, runtime handoff, phase proof ledger | No diagnosis, identity inference, hidden memory, or public action. |
| Visual Cortex Hero Console | First-viewport creator loop from signal to brand memory, specialist cells, proof packet, and human approval lock | Local proof | Visual Cortex hero console, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can route visitors to proof surfaces; it cannot publish, upload, access accounts, spend, write files, deploy, use likeness, pull private data, infer identity, post publicly, or broadcast Web3. |
| Visual Cortex Pipeline | Creator workflow from script to reviewable production packet | Prototype | Visual Cortex page, pipeline map, packet console | Publishing remains manual and approval-gated. |
| Visual Cortex Storyboard Proof Deck | Creator frames mapped to signal, memory, claim evidence, asset need, and approval lock before release handoff | Local proof | Visual Cortex storyboard deck, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The deck can explain frame-level proof; it cannot publish, upload assets, spend, use likeness, create public claims, distribute, access accounts, trigger outreach, write files, deploy, pull private data, or broadcast Web3. |
| Visual Cortex Release Handoff Ledger | Creator packet-to-public-memory handoff across transmission, carousel, caption, and gate | Local proof | Visual Cortex handoff ledger, release memory ledger, social carousel route, ai-services.json, asset manifest, tests | No public posting, deploy, spend, file write, asset upload, account access, audience targeting, outreach, private data pull, status promotion, or Web3 broadcast without explicit approval. |
| Visual Cortex Asset Lineage Receipt | Derivative creative assets mapped to source signal, proof source, frame decision, production packet, social derivative, and approval lock | Local proof | Visual Cortex lineage receipt, SVG asset, asset governance ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The receipt can clarify asset lineage; it cannot publish, upload, access accounts, use likeness, pay for distribution, deploy, write files, pull private data, post publicly, or broadcast Web3. |
| Visual Cortex Packet Anatomy | Creative packet internals mapped to source context, claim proof, cell notes, asset checklist, and approval lock before release handoff | Local proof | Visual Cortex packet anatomy, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The anatomy can clarify what a creator packet contains; it cannot publish, access accounts, upload, spend, trigger outreach, deploy, write files, use likeness, pull private data, generate public claims, or broadcast Web3. |
| Visual Cortex Render QA Gate | Rendered assets checked for format lock, text safe zone, proof marker, caption/download handoff, and approval lock before upload-ready handoff | Local proof | Visual Cortex render QA gate, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate can clarify asset readiness; it cannot upload, access accounts, post, buy ads, trigger outreach, write files, use likeness, deploy, pull private data, generate public claims, or broadcast Web3. |
| Visual Cortex Release Readiness Console | Draft, proof-needed, render-ready, and approval-locked packet states mapped before download, posting, upload, account access, or public motion | Local proof | Visual Cortex release readiness console, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can clarify packet state and review handoff; it cannot publish, upload, access accounts, schedule posts, buy ads, target audiences, trigger outreach, write files, deploy, pull private data, mutate metadata, or broadcast Web3. |
| Visual Cortex Delivery Format Matrix | Carousel frame, story or reel cover, transmission hero card, and collaboration packet preview mapped to format rule, proof requirement, handoff route, and blocked authority | Local proof | Visual Cortex delivery format matrix, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The matrix can clarify which surface a packet becomes; it cannot upload, access accounts, post to social, buy ads, target audiences, trigger outreach, write files, deploy, mutate metadata, commit scope, pull private data, or broadcast Web3. |
| Visual Cortex Creator Handoff Simulator | Brand launch, product demo, transmission carousel, and sprint signals mapped to packet, proof route, approval boundary, and allowed next step | Local proof | Visual Cortex handoff simulator, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The simulator can clarify the next safe creator packet; it cannot generate assets, publish, post to social, access accounts, target audiences, spend, commit scope, write files, deploy, pull private data, trigger outreach, or broadcast Web3. |
| Financial Organisms | Web3 research and simulation | Research | Trust-layer map, simulation console, proof page | No hidden wallet authority or broadcast path. |
| Financial Organisms Hero Console | First-viewport Web3 trust loop from read-only context to off-chain simulation, unsigned packet, custody owner, and broadcast lock | Local proof | Financial Organisms hero console, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can route visitors to proof surfaces; it cannot connect wallets, handle private keys, create transaction objects, request approvals, sign, broadcast, spend, move money, provide individualized financial advice, promise yield, pull private data, mutate accounts, deploy, post publicly, or grant Web3 authority. |
| Financial Role-to-Packet Router | Builder, investor, operator, and protocol-team intent translated into first artifact, proof route, and authority lock | Local proof | Financial role router, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The router can clarify Web3 product paths and proof routes; it cannot personalize, infer identity, connect wallets, handle private keys, create transaction objects, request approvals, sign, broadcast, spend, deploy, post publicly, pull private data, promote status, or promise yield. |
| Web3 Custody Boundary Map | Read-only observer, simulation cell, approval owner, and broadcast lock lanes before scenario interaction | Local proof | Financial Organisms custody boundary map, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The map can clarify custody and approval ownership; it cannot handle seed phrases, private keys, wallet sessions, transaction objects, approvals, allowances, signing, spending, voting, public money claims, individualized advice, or Web3 broadcast. |
| Web3 Evidence Boundary Router | Source permission, chain read, off-chain simulation, unsigned packet, and broadcast lock before scenario interaction | Local proof | Financial Organisms evidence boundary router, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The router can clarify where evidence stops before scenario selection; it cannot pull private data, infer identity, connect wallets, handle private keys, poll live prices, create transaction objects, request approvals, sign, spend, promise yield, provide individualized advice, or broadcast Web3. |
| Web3 Unsigned Packet Forge | Intent, sources, off-chain simulation, risk, approval question, and broadcast lock fields inside the review packet | Local proof | Financial Organisms packet forge, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The forge can explain unsigned packet structure; it cannot connect wallets, poll live prices, create transaction objects, request approvals, sign, broadcast, spend, move money, promise yield, provide individualized advice, write wallets, or access accounts. |
| Web3 Broadcast Lock Proof Deck | Source freshness, off-chain delta, risk budget, custody owner, approval question, and broadcast lock before value motion | Local proof | Financial Organisms broadcast lock deck, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The deck can explain why broadcast stays locked; it cannot connect wallets, sign, broadcast, spend, create transaction objects, approve wallets, pull private data, provide individualized financial advice, or move money. |
| Financial Organisms Value-Motion Readiness Ledger | Source freshness, risk budget, authority owner, and proof return before any value motion is considered | Local proof | Financial Organisms readiness ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger can return proof, refusal, research notes, or reviewed next-step packets; it cannot create motion from unsourced claims, stale data, yield promises, individualized advice, private keys, wallet approvals, account access, deployment, posting, spending, wallet writes, private data pulls, or Web3 broadcast without explicit approval. |
| Web3 Value Motion Receipt | Request record, source bundle, simulation delta, risk owner, human decision, and broadcast lock inside the final review artifact | Local proof | Financial Organisms receipt surface, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The receipt can explain what a builder or protocol team reviews; it cannot connect wallets, request approvals, sign, broadcast, spend, create transaction objects, poll live prices, provide individualized financial advice, promise yield, deploy, post publicly, pull private data, access accounts, or move money. |
| Brain Cell Architecture | Capability research, sandbox, approval, integration | Experimental | Brain Cell page, architecture docs, proof gates | New cells need tests and approval before integration. |
| Brain Cell Hero Console | First-viewport self-evolution loop from problem signal to research packet, sandbox proof, integration gate, and human approval lock | Local proof | Brain Cell hero console, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can route visitors to proof surfaces; it cannot execute code, write files, install dependencies, approve itself, deploy, post publicly, spend, pull private data, mutate registries, claim private self-awareness, claim live telemetry, or broadcast Web3. |
| Brain Cell Failure Triage Console | Prompt gap, missing tool, unsafe request, and durable cell candidate classified before a new cell can be proposed | Local proof | Brain Cell failure triage console, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can explain failure classification; it cannot execute code, write files, install dependencies, call private tools, approve integration, change runtime state, deploy, post publicly, spend, pull private data, claim private self-awareness, claim live telemetry, or broadcast Web3. |
| Brain Cell Permission Ladder | Observed failure, proposed source, sandbox proof, creator approval, and limited integration as explicit permission rungs | Local proof | Brain Cell permission ladder, SVG asset, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ladder can explain permission state; it cannot execute code, write files, install dependencies, approve integration, expand authority, deploy, post publicly, spend, pull private data, change runtime state, or broadcast Web3. |
| Brain Cell Sandbox Evidence Board | Fixture replay, dependency fence, diff scope, immune review, and rollback proof before integration | Local proof | Brain Cell evidence board, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The board can explain sandbox evidence; it cannot execute code, write files, install dependencies, approve integration, expand authority, deploy, post publicly, spend, pull private data, or broadcast Web3. |
| Brain Cell Integration Gate | Quarantine state, staging fixture, registry memory, approval owner, rollback route, and integration receipt before a cell joins | Local proof | Brain Cell integration gate, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate can explain integration readiness; it cannot execute code, write files, install dependencies, approve integration, expand authority, deploy, post publicly, spend, pull private data, change runtime state, or broadcast Web3. |
| Brain Cell Evolution Memory Receipt | Patch record, test memory, approval owner, rollback route, and locked authority recorded after integration review | Local proof | Brain Cell evolution memory receipt, SVG asset, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The receipt can explain what the organism remembers after a candidate cell passes review; it cannot install cells, write files, deploy, change status, mutate a registry, pull private data, spend, post publicly, connect wallets, sign, or broadcast Web3. |
| Brain Cell Growth Boundary Checkpoint | Proposal, sandbox proof, creator approval, rollback, public proof route, and unknowns before graduation | Local proof | Brain Cell growth boundary checkpoint, SVG asset, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The checkpoint can explain graduation evidence; it cannot execute code, write files, install dependencies, approve itself, self-deploy, post publicly, spend, pull private data, claim private self-awareness, claim live telemetry, change runtime state, expand authority, or broadcast Web3. |
| Transmissions | Public build records and release packets | Live for published pages | Transmission pages, schema, social packet, tests | Approved transmissions should include Instagram carousel packet and manual posting gate. |
| Build With Us | Collaboration intake and first packet | Live | Build page, engagement fit, collaboration packet map | Intake starts with goal, boundary, proof need, and owner. |
| Conversation Gateway | Homepage Brain chat routing, starter prompts, Brain Source Rail, Brain Availability Receipt, Brain Availability Receipt Visual, website-awareness starter check, receipt preview, chat source status strip, response contract, public website context ledger, public context mesh, Brain Context Parity Receipt, Brain Source Switchboard, Brain Answer Trail, Brain Answer Firewall, Brain Answer Specimen, Brain Awareness Gate, same-origin API, runtime response receipt, and client boundary repair | Prototype | CTA gateway panel, starter prompt chips, Brain Source Rail, Brain Availability Receipt, Brain Availability Receipt Visual, Brain receipt preview, chat source status strip, Brain response contract, Brain public context ledger, Brain public context mesh, Brain Context Parity Receipt, Brain Source Switchboard, Brain Answer Trail, Brain Answer Firewall, Brain Answer Specimen, Brain Awareness Gate, Brain response receipt, client boundary repair marker, /api/chat, proof ledger link, asset manifest, tests | The Brain can explain, route, draft, and return typed signal, next route, proof packet, and human handoff from attached public website context only. The Brain Source Rail now appears before starter prompts so a first-time visitor sees Manual Brain Mode, public site map plus proof routes, and explain-route-stop before action before choosing a role. The Brain Availability Receipt then makes /api/chat prototype availability explicit before prompts: http-503 request-limit-unavailable or network failure is a bounded local fallback state, awareness prompts repair to Manual Brain Mode, other prompts keep proof receipt behavior with a client availability notice, and live parity still requires the awareness smoke to pass. Its textless support SVG visualizes endpoint, fallback, parity, and blocked authority while all critical labels remain in semantic HTML and bilingual copy. Prompt focus or hover previews the same receipt profile map without submitting data, including a website-awareness check that routes to the public context ledger and Proof Source Router before asking whether the Brain knows its own website. The chat modal now exposes Manual Brain Mode, public website context, and the Brain Awareness Checkpoint before the message stream begins. The same-origin API validates a prompt, answers website-awareness questions locally in Manual Brain Mode before limiter or upstream routing, checks the durable request-limit guard for non-awareness prompts before upstream routing, attaches bounded public website context to other upstream prompts, repairs upstream website-context identity overclaims such as "I am Unwind Code," "home base," "living intelligence," or "central nervous system" before responding, and returns a bounded receipt fallback when upstream is unavailable. If the production limiter is unavailable for a non-awareness prompt, the API fails closed with Request limit unavailable and the homepage converts that into a visible local proof receipt. The context parity receipt makes the live release-smoke rule visible: awareness answers must return Manual Brain Mode from same-origin-public-context with upstream_status not_required, and fail if they answer from supabase-edge-function or claim institutional/private memory. The Brain Source Switchboard makes source outcomes visible before chat: public context can answer, upstream drift must be repaired, and authority requests must hold for a human. The answer trail makes the safe path visible before chat: attach public sources, answer inside the context fence, return proof, and stop at human authority. The answer firewall names the awareness test prompt, required Manual Brain Mode response, forbidden "I am Unwind Code," "home base," "living intelligence," or private self-awareness claim, and first proof route before chat. The answer specimen gives visitors accepted Manual Brain Mode wording, required evidence fields, rejected overclaim language, and the proof route before they trust the answer. The awareness gate lets visitors inspect sources, routes, proof, and unknown handling before chat. The client boundary fallback is defense in depth: if a website-awareness response reaches the UI with the wrong source, wrong upstream_status, private-awareness language, a non-2xx `/api/chat` response, or a network failure, the visible reply becomes Manual Brain Mode public-context wording and the receipt is marked with data-parity-repair="website-awareness-boundary"; non-awareness `Request limit unavailable` failures are marked with a local client availability notice and routed to proof instead of implying a downstream Brain run. This improves the visitor response while live parity still fails until `/api/chat` returns same-origin-public-context with upstream_status not_required. It cannot claim private self-awareness, execute files, move money, post publicly, pull private data, deploy, use hidden memory, infer identity, personalize, change statuses, or broadcast Web3. |
| Homepage Decision Handoff | Final CTA role routing from visitor intent to first artifact, proof route, safe next action, and receipt visual | Live | CTA decision handoff, decision handoff receipt SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The handoff routes builders, investors, users, protocols, subscribers, and collaborators before chat or subscription; the decorative receipt cannot carry critical text, submit data, open chat, subscribe, deploy, spend, post publicly, trigger outreach, pull private data, store hidden memory, infer identity, profile subscribers, connect wallets, sign transactions, custody assets, or broadcast Web3. |
| Homepage Consent Receipt | Final CTA consent boundary across chat prompt, email subscription, proof return, and blocked measurement | Local proof | CTA consent receipt, Brain response contract, Subscriber Signal Console, Source Translation Ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The receipt makes explicit inputs and blocked authority visible before conversion; it cannot store hidden memory, infer identity, personalize, lead score, trigger outreach, deploy, post publicly, spend, pull private data, run hidden telemetry, or broadcast Web3. |
| Homepage AI and Web3 Lab Circuit | First-scroll mental model for signal, organism route, Web3 authority boundary, proof memory, and human-approved handoff | Local proof | Homepage lab circuit, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The circuit explains the lab; it cannot personalize, infer intent, store hidden memory, execute, deploy, post, spend, open chat, subscribe, trigger outreach, pull private data, approve wallets, sign transactions, or broadcast Web3. |
| Homepage Production Proof Pulse | Latest approved public release translated into tests, production checkpoint artifact, conversion proof, discovery metadata, and authority boundary | Live | Homepage proof pulse, production checkpoint JSON, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The pulse records release memory only; it cannot deploy, promote aliases, roll back, monitor users, post, spend, trigger outreach, pull private data, profile visitors, change status, or broadcast Web3. |
| System State Console | Current operating reality across routes, gateway, transmissions, Web3 simulation, intake, same-origin status receipt, and Brain awareness release gate | Mixed: Live, Prototype, Research | Homepage state console, live /api/status receipt, Brain Awareness Checkpoint, llms.txt, ai-services.json, asset manifest, tests | The homepage must name what is real now and which authority remains manual before asking for trust. The receipt hydrates from public status JSON, exposes release-gate criteria, and falls back to static copy; it cannot run smoke checks, approve parity, poll users, read private data, mutate status, deploy, spend, post, or broadcast Web3. |
| Same-Origin Organism Status API | Public organism state reflected as machine-readable routes, proof links, endpoint states, release contract version, Brain awareness release gate, and authority boundaries | Live | /api/status, Organism State Ledger, System State Console, Brain Awareness Checkpoint, ai-services.json, asset manifest, tests | The endpoint is public state reflection only; it cannot read private data, personalize, infer identity, monitor users, mutate state, execute work, write files, deploy, spend, post publicly, sign transactions, run live smoke, approve parity, or broadcast Web3. |
| Authority Gradient | Responsibility ladder from public observation to proof-gated public motion | Mixed: Live, Prototype, Experimental, Research | Homepage authority gradient, proof authority gate, llms.txt, ai-services.json, tests | Every authority rung must name allowed behavior, proof, stop condition, state label, and route before any high-risk action is implied. |
| Architecture Hero Console | First-viewport organism anatomy across Gateway, Cortex, Memory, Cells, Immune lock, and Proof return | Local proof | Architecture page hero console, architecture-hero-console SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The hero can explain public architecture and route to proof surfaces; it cannot submit prompts, execute code, write files, deploy, post publicly, spend, pull private data, sign transactions, change status, or broadcast Web3. |
| Architecture Gateway Channel Matrix | Web, Brain chat, mobile node, protocol/Web3, and scheduled review signals mapped into proof-returning Gateway routes | Local proof | Architecture page gateway matrix, architecture-gateway-matrix SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | Channels can bring signal into the organism, but cannot grant private data access, device permissions, hidden telemetry, file writes, deploys, public posting, spend, wallet authority, signing, or Web3 broadcast. |
| Digital Biology Ledger | Organism metaphors mapped to real architecture, proof routes, motion meaning, and stop conditions | Local proof | Architecture page digital biology ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | Infinity, reflection, recursion, neural growth, cognitive evolution, living systems, intelligence organisms, and digital biology cannot imply live autonomy, hidden memory, diagnosis, identity inference, deployment, public posting, private data pulls, or Web3 broadcast. |
| Architecture Search Intent Router | AI agents, Web3 architecture, autonomous systems, cognitive agents, on-chain intelligence, AI organism design, and agentic software architecture mapped into organism layers, proof routes, next paths, and blocked claims | Local proof | Architecture page search intent router, architecture-search-intent-router SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | Search language cannot imply live autonomy, wallet motion, private memory, deployment, public posting, execution authority, hidden telemetry, identity inference, spending authority, private data pulls, or Web3 broadcast. |
| Architecture Runtime Trace Console | One visitor signal traced through intake, cortex route, memory recall, specialist cell work, immune review, and proof return | Local proof | Architecture runtime trace console, architecture-runtime-trace-console SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console explains runtime architecture only; it cannot submit prompts, call private tools, mutate files, deploy, post publicly, spend, connect wallets, sign, change status, or broadcast Web3. |
| Architecture Authority Mesh | Observe, reflect, draft, sandbox, approval, and public motion lanes before authority expands | Local proof | Architecture authority mesh, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The mesh can explain authority lanes; it cannot execute, deploy, post, spend, pull private data, connect wallets, sign, or broadcast Web3. |
| Architecture Approval Packet | Request record, evidence bundle, risk owner, exact approval question, and locked motion path before authority expands | Local proof | Architecture approval packet, architecture-approval-packet SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The packet can explain approval handoff; it cannot approve itself, mutate files, deploy, publish, spend, pull private data, connect wallets, sign, broadcast Web3, change status, or contact anyone. |
| Memory Recall Receipt | Source trace, freshness gate, use boundary, and proof return before recalled memory shapes an answer | Local proof | Architecture recall receipt, memory-recall-receipt SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The receipt can explain bounded recall; it cannot store hidden memory, infer identity, personalize, pull private data, execute, deploy, post, spend, change status, connect wallets, sign, or broadcast Web3. |
| Website Awareness Console | Public site map, awareness receipts, approved memory, and blocked private claims before the Brain answers website-awareness questions | Local proof | Architecture website awareness console, website-awareness-console SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can explain same-origin public context and approved memory; it cannot chat with the Brain, scrape private data, infer identity, read analytics, mutate files, deploy, post, spend, connect wallets, sign, change status, or broadcast Web3. |
| Build Hero Console | First-viewport visitor signal mapped into builder, investor, user, subscriber, protocol, and collaborator proof routes | Local proof | Build With Us hero console, build-hero-console SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can route intent to first packets and proof surfaces; it cannot submit data, start work, trigger outreach, write files, deploy, post publicly, spend, pull private data, sign transactions, or broadcast Web3. |
| Build Conversion Packet Ledger | Visitor roles mapped to first packet, proof route, authority boundary, and next route before intake | Local proof | Build With Us conversion packet ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger cannot execute work, deploy, post publicly, spend, trigger outreach, pull private data, profile subscribers, diagnose users, store hidden memory, sign transactions, or broadcast Web3. |
| Protocol Readiness Gate | Protocol, fund, and operator Web3 interest mapped to read-only context, off-chain simulation, unsigned packet, approval owner, and broadcast lock | Local proof | Build With Us protocol readiness gate, protocol-readiness-gate SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate can clarify Web3 readiness; it cannot connect wallets, request approvals, create transaction objects, sign, broadcast, custody assets, move money, provide individualized financial advice, poll private data, deploy, post publicly, or begin work without explicit approval. |
| Build Signal Composer | Builders, investors, users, subscribers, protocols, and collaborators preview what to send, what returns, proof route, blocked authority, and next path before conversation | Local proof | Build With Us signal composer, build-signal-composer SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The composer cannot submit messages, open hidden chat, start work, trigger outreach, write files, deploy, spend, post publicly, pull private data, connect wallets, sign transactions, or broadcast Web3. |
| Build Intake Readiness Receipt | First build signal classified as ready to scope, needing research, authority blocked, or missing proof before work starts | Local proof | Build With Us intake readiness receipt, build-intake-readiness-receipt SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The receipt cannot submit data, open chat, start work, trigger outreach, write files, deploy, spend, post publicly, pull private data, connect wallets, sign transactions, broadcast Web3, or promote status without proof. |
| First Sprint Scope Gate | First message converted into signal, boundary, proof, and handoff checkpoints before engagement size is chosen | Local proof | Build With Us scope gate, first-sprint-scope-gate SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate cannot submit data, start outreach, write files, deploy, spend, post publicly, pull private data, connect wallets, sign transactions, broadcast Web3, or begin work without explicit approval. |
| Research Organisms Hero Console | First-viewport source-bound proof path across source packet, question map, bounded experiment, synthesis, and publication gate | Local proof | Research Organisms hero console, route CSS, textless SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can explain research method; it cannot fabricate citations, scrape private context, imply affiliation, promote speculation into certainty, publish unattended, deploy, spend, pull private data, create live status, or broadcast Web3. |
| Research Translation Ledger | Research-to-product translation across external patterns, backend behavior, bounded experiments, and public memory | Local proof | Research Organisms translation ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger cannot imply affiliation, copied design, decorative intelligence, hidden telemetry, private memory, live autonomy, deployment, posting, outreach, spend, private data pull, status promotion, or Web3 broadcast. |
| Trust Progression Rail | Visitor emotional sequence from curiosity to bounded invitation | Mixed: Live, Prototype | Homepage trust progression rail, llms.txt, ai-services.json, tests | Emotional progression is public navigation, not profiling; each stage must expose route, proof, state, and authority boundary. |
| Public Learning Loop | Transmission archive as release memory and public research cadence | Mixed: Live, Research | Homepage public learning loop, transmissions, llms.txt, ai-services.json, tests | Release beats must expose state, proof artifact, boundary, and next route without implying autonomous publishing or live roadmap authority. |
| Transmissions Hero Console | First-viewport proof routing across latest build, whitepaper, safety, Web3, social packet, and collaboration paths | Local proof | Transmissions hero console, transmissions-hero-console SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can route proof and explain releases; it cannot publish, post, deploy, spend, trigger outreach, pull private data, promote status, connect wallets, sign, or broadcast Web3. |
| Transmission Release Memory Ledger | Latest transmissions mapped to date, state, change, proof, boundary, and next inspection route | Local proof | Transmissions release memory ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger cannot publish, post, deploy, spend, trigger outreach, pull private data, promote status, or broadcast Web3. |
| Vision Hero Constellation | First-viewport roadmap lanes across Now, Product organisms, Web3 value, Culture, and Coordination mapped to proof routes and blocked authority | Local proof | Vision hero constellation, vision-hero-constellation SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The constellation can explain long-range lanes and route to proof surfaces; it cannot promote roadmap status, create hidden memory, infer identity, connect wallets, deploy, post publicly, spend, pull private data, sign transactions, or broadcast Web3. |
| Vision Proof-to-Product Bridge | Future claims translated into current proof routes and product paths for memory, Web3, interface, cell growth, and collaboration | Local proof | Vision proof-to-product bridge, vision-proof-product-bridge SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The bridge can clarify current inspection paths; it cannot promote future status, create hidden memory, infer identity, connect wallets, sign, deploy, post publicly, spend, pull private data, mutate files, start hidden work, or broadcast Web3. |
| Vision Horizon Readiness Gate | Memory integrity, value motion, culture continuity, and machine coordination evidence required before future lanes earn more status | Local proof | Vision page horizon gate, route-scoped CSS, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate cannot promote 2028 or 2030 lanes to live status, create hidden memory, infer identity, connect wallets, sign, deploy, post publicly, spend, monetize culture, pull private data, or broadcast Web3. |
| Philosophy Hero Console | First-viewport doctrine path across light, clarity, human authority, proof return, and Manual Brain Mode public-context boundaries | Local proof | Philosophy hero console, route CSS, textless SVG, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console can explain doctrine and route proof; it cannot diagnose, infer identity, claim private self-awareness, execute work, deploy, spend, post publicly, pull private data, connect wallets, sign, or broadcast Web3. |
| Human Authority Covenant | Draft, simulate, request, and refuse lanes mapped to allowed action, approval requirement, refusal condition, and proof returned | Local proof | Philosophy covenant, SVG asset, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The covenant can explain authority boundaries; it cannot write files, submit externally, change status, connect wallets, sign, create transaction objects, spend, post publicly, pull private data, claim implied consent, grant broad autonomy, or broadcast Web3. |
| Lab Resource Index | Footer-level orientation across home, organism paths, proof contracts, public memory, and build gateway | Live | Homepage footer resource index, llms.txt, ai-services.json, implementation packet, tests | The index is static public navigation only; no personalization, hidden memory, telemetry claim, execution authority, public posting, deployment, spending, outreach, or Web3 broadcast. |
| Proof Hero Console | First-viewport trust routing across artifacts, public status, authority boundary, runtime budget, live parity, and build path | Local proof | Proof hero console, proof-hero-console SVG, route CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The console routes public evidence and stop conditions only; it cannot run tests, call APIs, open chat, submit data, deploy, publish, spend, trigger outreach, pull private data, infer identity, connect wallets, sign transactions, broadcast Web3, mutate status, or declare live parity. |
| Proof Source Router | First proof choice mapped across architecture, organism, runtime, Web3, transmission, and collaboration sources | Local proof | Proof source router, proof-source-router SVG, route-scoped CSS, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The router is static source selection with semantic cards; it cannot execute, personalize, infer identity, open chat, submit data, deploy, spend, publish, pull private data, connect wallets, sign transactions, or broadcast Web3. |
| Brain Awareness Checkpoint | Website-awareness prompt mapped to Manual Brain Mode response, same-origin source, upstream bypass, blocked overclaim language, request-limit availability failure, and release-smoke command | Local proof | Proof page checkpoint, brain-awareness-checkpoint SVG, verify:brain-awareness script, /api/chat contract, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The checkpoint cannot call the model, open chat, deploy, promote aliases, mutate status, monitor users, post publicly, spend, pull private data, claim private self-awareness, grant wallet authority, or broadcast Web3; if live answers from upstream, overclaims awareness, returns non-2xx, or reports Request limit unavailable, production parity fails. |
| Same-Origin Status Mirror | Public /api/status payload translated into visitor-readable organism state, endpoint receipts, release gate requirements, proof routes, and authority boundaries | Local proof | Proof page status mirror, status-mirror SVG, /api/status contract, System State Console, Organism State Ledger, Brain Awareness Checkpoint, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The mirror is static explanation only; it cannot call APIs, poll visitors, mutate status, run smoke checks, deploy, promote aliases, post publicly, spend, pull private data, sign transactions, connect wallets, or broadcast Web3. |
| Proof Page | Evidence and authority ledger | Live | Asset governance, trust diligence console, tests | Proof surfaces must name limitations near claims. |
| Implementation Contract Surface | Machine-readable evolution packet made visible before future runtime work | Local proof | Proof page implementation contract, JSON packet, llms.txt, ai-services.json, asset manifest, tests | Future React, Next.js, Framer, GSAP, Three.js, WebGL, dependency, or deployment work must map to packet gates without granting autonomy. |
| Migration Blueprint Ledger | Future implementation architecture made visible across Next.js App Router, server-rendered defaults, client leaves, Framer Motion, Three.js, design tokens, assets, and performance budgets | Local proof | Proof page migration blueprint ledger, implementation packet, runtime budget ledger, llms.txt, ai-services.json, asset manifest, tests | The blueprint cannot approve migration, dependencies, deployment, telemetry, runtime authority, public posting, private data pulls, status changes, or Web3 broadcast. |
| Digital Biology Token Ledger | Design-token families mapped to void, glass, signal, proof, boundary, shape, spacing, and motion timing before future runtime expansion | Local proof | Proof page token ledger, implementation packet, asset manifest, llms.txt, ai-services.json, tests | The ledger cannot approve migration, install dependencies, deploy, personalize, run a live theme engine, monitor users, post, spend, pull private data, change status, or broadcast Web3 transactions. |
| Source Translation Ledger | Current Anthropic homepage principles translated into Unwind-native proof, IA, release memory, research separation, human signal, resource routing, consent boundaries, and implementation confidence | Live | Proof page source translation ledger, current source snapshot, audit, llms.txt, ai-services.json, asset manifest, tests | Source inspiration is method, not mimicry; stale source memory, affiliation, endorsement, hidden telemetry, consent laundering, status promotion, deployment, execution, posting, spend, private data pull, copied section rhythm, or Web3 broadcast are blocked. |
| Source Freshness Gate | Dated source review, observed current patterns, Unwind adoption rule, and stale-source stop condition before future source-inspired UX work moves | Live | Proof page source freshness gate, current source snapshot, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate records provenance only; it cannot imply endorsement, affiliation, live source monitoring, copied design, migration approval, deployment approval, telemetry, personalization, or runtime authority. |
| Experience Principles Ledger | Full research matrix across IA, storytelling, scroll choreography, motion, hierarchy, typography, navigation, attention, emotion, and performance | Local proof | Proof page experience principles ledger, audit, implementation packet, llms.txt, ai-services.json, asset manifest, tests | Research becomes build guidance; the ledger cannot imply endorsement, copied design, telemetry, emotional profiling, migration approval, deployment, execution, posting, spend, private data pull, or Web3 broadcast. |
| Runtime Budget Ledger | Production performance strategy across semantic HTML, CSS/SVG motion, shared JavaScript, media packets, future Three/WebGL, and same-origin intake | Live | Proof page runtime budget ledger, implementation packet, llms.txt, ai-services.json, asset manifest, tests | Depth has a cost ceiling; the ledger cannot install dependencies, monitor users, enforce telemetry, deploy, execute, post, spend, pull private data, or broadcast Web3 transactions. |
| Access and Mobile Ledger | Accessibility and mobile strategy across keyboard route recovery, compact glass navigation, reduced motion, language parity, text-first proof, and bounded intake | Live | Proof page access/mobile ledger, implementation packet, llms.txt, ai-services.json, asset manifest, tests | Access is proof; the ledger cannot certify compliance, personalize, monitor users, enforce telemetry, deploy, execute, post, spend, pull private data, or broadcast Web3 transactions. |
| System Reflection Ledger | Backend-to-frontend reflection across signal routing, conversation gateway, public memory, Infinity Mirror, Web3 simulation, and Brain Cell growth | Local proof | Proof page system reflection ledger, implementation packet, llms.txt, ai-services.json, asset manifest, tests | The living interface must map to real organism layers; the ledger cannot monitor users, infer identity, execute, deploy, post, spend, pull private data, change status, or broadcast Web3 transactions. |
| Rollout Readiness Ledger | Production rollout plan across clarity, proof proximity, runtime reflection, migration option, and living proof phases | Live | Proof page rollout readiness ledger, implementation packet, llms.txt, ai-services.json, asset manifest, tests | Release sequencing is proof; the ledger cannot deploy, promote aliases, monitor releases, roll back automatically, post, spend, pull private data, or broadcast Web3 transactions. |
| Production Checkpoint Ledger | Approved deployment proof across 142 local tests, production build, runtime budget, Vercel alias, live homepage/API checks, and manual approval boundary | Local proof | Proof page production checkpoint ledger, checkpoint JSON, runtime budget evidence, llms.txt, ai-services.json, asset manifest, sitemap, tests | The checkpoint records one approved deploy; it cannot approve future deployment, promote aliases, roll back, monitor users, post, spend, pull private data, change status, or broadcast Web3 transactions. |
| Live Parity Gate | Local proof, live alias checks, deploy approval, and completion claims separated before public goal completion | Local proof | Proof page live parity gate, rollout readiness ledger, production checkpoint, runtime budget evidence, implementation packet, llms.txt, ai-services.json, asset manifest, tests | The gate cannot deploy, promote aliases, roll back, monitor users, approve completion, post publicly, spend, pull private data, write files, change status, or broadcast Web3 transactions. |
| Experience Evolution Acceptance Ledger | Active Anthropic-to-Unwind objective mapped to evidence lanes for source freshness, identity preservation, backend reflection, experience research, implementation architecture, and rollout authority | Local proof | Proof page acceptance ledger, source freshness gate, system reflection ledger, implementation contract, rollout readiness ledger, production checkpoint, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger is acceptance evidence only; it cannot declare future work complete, approve dependencies, migrate frameworks, deploy, post publicly, spend, pull private data, or broadcast Web3. |
| Completion Audit Ledger | Active frontend evolution goal audited across proven surfaces, immersive asset governance, blueprint-only architecture, live release proof, and blocked authority | Local proof | Proof page completion audit ledger, completion audit JSON, asset governance ledger, production recommendation gate, live parity gate, llms.txt, ai-services.json, asset manifest, sitemap, implementation packet, tests | The ledger prevents completion-by-vibe and decorative asset expansion; it cannot mark the goal complete, generate assets, approve dependencies, migrate frameworks, approve WebGL, deploy, post publicly, spend, pull private data, write files, change status, or broadcast Web3. |
| Requirement Coverage Ledger | Named Experience Evolution deliverables mapped to source research, UX audit, design research, IA, component, motion, digital biology, implementation stack, access, SEO, performance, rollout, and production-proof lanes | Local proof | Proof page requirement coverage ledger, source freshness gate, implementation contract, motion contract ledger, digital biology ledger, migration blueprint, access/mobile ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The ledger prevents scope shrink but cannot declare completion, approve migration, install dependencies, deploy, monitor users, post publicly, spend, pull private data, change status, or broadcast Web3 transactions. |
| Objective Deliverable Index | Exact objective outputs mapped one-by-one to evidence routes, state labels, and stop conditions | Local proof | Proof page objective deliverable index, experience principles ledger, implementation contract, migration blueprint, access/mobile ledger, discovery ledger, rollout ledger, runtime budget ledger, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The index prevents named deliverables from hiding inside broad lanes; it cannot declare completion, approve migration, install dependencies, deploy, post publicly, spend, pull private data, change status, or broadcast Web3 transactions. |
| Production Recommendation Gate | Production-ready recommendation criteria mapped across current static surfaces, React/Next migration, Framer/GSAP motion, Three.js depth, tokens, assets, and release authority | Local proof | Proof page production recommendation gate, implementation contract, migration blueprint, motion meaning ledger, Infinity Mirror depth gate, asset governance, runtime budget, live parity gate, llms.txt, ai-services.json, asset manifest, implementation packet, tests | The gate prevents recommendations from becoming production work without proof, fallback, state, evidence route, and blocked authority; it cannot approve dependencies, migrate frameworks, deploy, post publicly, spend, pull private data, write files, change status, or broadcast Web3 transactions. |

## Component Recommendations

### Organisms Hero Console

Purpose: Let a first-time visitor choose the right organism path before the full index expands, while keeping proof, maturity, and authority boundaries visible in the first viewport.

Fields:

- Visual Cortex route.
- Infinity Mirror route.
- Financial Organisms route.
- Brain Cell Architecture route.
- Research Organisms route.
- Shared proof dock.
- Authority boundary.
- Textless ecosystem asset: `assets/visuals/organisms-hero-console.svg`.

Rules:

- The console must sit in the first viewport before the Organism Translation Layer.
- Route cards must remain semantic links with visible focus states.
- The SVG must remain decorative and textless; all meaning lives in HTML and i18n copy.
- The console cannot personalize, infer intent, open chat, execute, deploy, publish, spend, pull private data, install cells, connect wallets, sign, broadcast Web3, or promote status.

### Organism Product Pathway Console

Purpose: Let a visitor choose a flagship product path by the signal they bring, the loop that will handle it, the proof artifact they should expect, and the authority that remains human-owned.

Fields:

- Flagship organism lane.
- Incoming signal.
- Organism loop.
- Proof artifact.
- Authority stop.
- Next route.
- Textless pathway asset: `assets/visuals/organism-product-pathway-console.svg`.

Rules:

- The console must sit after the Organism Fit Matrix and before the Organism Identity Constellation.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- Visual Cortex, Infinity Mirror, Financial Organisms, and Brain Cell Architecture must each name a proof artifact and a blocked authority edge before the next route.
- The console cannot personalize, infer intent, execute work, deploy, post publicly, spend, pull private data, install cells, connect wallets, sign transactions, or broadcast Web3.

### Organism Operating Theater

Purpose: Make the flagship ecosystem feel like a coordinated operating surface without implying shared unchecked authority.

Fields:

- Flagship organism lane.
- Input.
- Specialist cell.
- Proof return.
- Authority lock.
- Textless theater asset: `assets/visuals/organism-operating-theater.svg`.

Rules:

- The theater must sit after the Organism Product Pathway Console and before the Organism Identity Constellation.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- Visual Cortex, Infinity Mirror, Financial Organisms, and Brain Cell Architecture must each name a proof return and authority lock.
- The theater cannot personalize, infer intent, execute work, open hidden chat, deploy, post publicly, spend, pull private data, install cells, connect wallets, sign transactions, broadcast Web3, change status, or move authority across organisms.

### Organism Status Rail

Purpose: Make product maturity visible across all organism pages.

Fields:

- Label: Concept, Research, Prototype, Experimental, or Live.
- What works now.
- What is still manual.
- What proof exists.
- What authority is blocked.

### Capability Ledger Cards

Purpose: Show what a capability can do, cannot do, and where proof lives.

Fields:

- Capability.
- Input.
- Output.
- Memory boundary.
- Tool boundary.
- Approval boundary.
- Evidence link.

### Vision Hero Constellation

Purpose: Make the Vision first viewport explain future ambition as proof-gated lanes before a reader trusts long-range roadmap language.

Fields:

- Roadmap lane.
- Current proof posture.
- Proof route.
- Blocked authority.
- Textless decorative SVG.

Rules:

- Now, Product organisms, Web3 value, Culture, and Coordination must each point to an existing proof or organism route.
- The console must appear before the roadmap observatory so the first viewport frames future claims as evidence-gated rather than promotional.
- The SVG remains decorative and textless; semantic links, bilingual copy, durable anchors, and route CSS carry all meaning.
- The constellation cannot promote roadmap status, create hidden memory, infer identity, connect wallets, deploy, post publicly, spend, pull private data, sign transactions, monetize culture, or broadcast Web3.

### Vision Proof-to-Product Bridge

Purpose: Translate future-facing Vision claims into current product paths and proof routes before the roadmap asks for more authority.

Fields:

- Future claim.
- Current proof.
- Product path.
- Blocked authority.
- Next proof route.
- Textless decorative SVG.

Rules:

- Memory continuity, Web3 value, interface proof, cell growth, and collaboration must each point to an existing proof surface and product path.
- The bridge must sit between the roadmap observatory and the chronological roadmap so future language becomes actionable before the reader scans dates.
- The SVG remains decorative and textless; native radio controls, bilingual definition lists, durable anchors, and route CSS carry all meaning.
- The bridge cannot promote future status, create hidden memory, infer identity, connect wallets, sign, deploy, post publicly, spend, pull private data, mutate files, start hidden work, self-approve cells, or broadcast Web3.

### Infinity Mirror Hero Console

Purpose: Make the Infinity Mirror first viewport explain reflection as a bounded product organism before visitors enter the deeper emotional experience.

Fields:

- Human signal.
- Mirror reflection.
- Memory consent.
- Artifact return.
- Human authority boundary.
- Textless decorative SVG.

Rules:

- The console should sit inside the Infinity Mirror first viewport before the product brief.
- Signal, Mirror, Consent, Artifact, and Boundary cards must route to session, reflection loop, memory consent, first artifact, and authority proof surfaces.
- The SVG remains decorative and textless; semantic links, bilingual copy, durable anchors, and route CSS carry all meaning.
- The console cannot diagnose, infer identity, store hidden memory, make care decisions, trigger public action, deploy, post publicly, spend, pull private data, connect wallets, sign transactions, or broadcast Web3.

### Infinity Mirror Reflection Artifact Router

Purpose: Make the product route answer what the person receives first before the capability ledger becomes technical.

Fields:

- Reflection signal.
- First artifact.
- Proof route.
- Authority lock.
- Textless decorative SVG.

Rules:

- The router should sit after the product brief and before the capability ledger so state, identity, decision, and support signals become reviewable artifacts before deeper system boundaries.
- State, Identity, Decision, and Support panels must each name the signal, first artifact, proof route, and authority lock.
- The SVG remains decorative and textless; semantic panels, bilingual copy, durable anchors, and route CSS carry all meaning.
- The router cannot diagnose, infer identity, store hidden memory, make care decisions, handle crisis support, publish, write files, deploy, spend, pull private data, connect wallets, sign transactions, broadcast Web3, or create external consequences.

### Philosophy Hero Console

Purpose: Make the philosophy first viewport behave like an operating doctrine console instead of a manifesto block.

Fields:

- Light: lower suffering before scale.
- Clarity: explain state, risk, owner, and next step before motion.
- Human authority: ask before files, posts, spend, or Web3 motion.
- Proof return: route website-awareness trust to Manual Brain Mode proof.
- Manual mode: public context only, no hidden awareness claim.

Rules:

- The console should sit in the Philosophy first viewport before the Operating Doctrine Compass.
- It should use a textless SVG plus semantic proof-route cards so meaning remains bilingual, keyboard-readable, and available without motion.
- It cannot diagnose, infer identity, claim private self-awareness, execute work, deploy, spend, post publicly, pull private data, connect wallets, sign, or broadcast Web3.

### Human Authority Covenant

Purpose: Make the prime directive operational before visitors trust autonomy.

Fields:

- Draft lane.
- Simulate lane.
- Request lane.
- Refuse lane.
- Allowed now, approval required, refusal condition, and proof returned.

Rules:

- The covenant should sit after the Operating Doctrine Compass and before the broader operating doctrine brief.
- It should use a textless SVG plus semantic rows and definition lists so meaning remains bilingual, keyboard-readable, and available without motion.
- It cannot write files, submit externally, change status, connect wallets, sign, create transaction objects, spend, post publicly, pull private data, claim implied consent, grant broad autonomy, or broadcast Web3.

### Brain Cell Hero Console

Purpose: Make the self-evolution path understandable before the visitor reaches the deeper lifecycle, sandbox, and integration proof sections.

Fields:

- Problem signal.
- Research packet.
- Sandbox proof.
- Integration gate.
- Human approval lock.

Rules:

- The console should sit inside the Brain Cell first viewport before the product brief.
- It should use a textless SVG plus semantic proof-route links so the public meaning remains bilingual, keyboard-readable, and available without motion.
- It should route visitors to the capability ledger, cell swap protocol, sandbox evidence, integration gate, and authority gate.
- It cannot execute code, write files, install dependencies, approve itself, deploy, post publicly, spend, pull private data, mutate registries, claim private self-awareness, claim live telemetry, or broadcast Web3.

### Brain Cell Failure Triage Console

Purpose: Make the decision before self-evolution inspectable: not every repeated failure becomes a new cell.

Fields:

- Prompt gap.
- Missing tool.
- Unsafe request.
- Durable cell candidate.
- Signal, route, proof, and blocked authority for each class.

Rules:

- The console should sit after the Brain Cell capability ledger and before the lifecycle map.
- It should use a textless SVG plus native radio controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It should route prompt gaps to clarification, tool gaps to research interfaces, unsafe requests to approval freeze/refusal, and durable candidates to lifecycle proof.
- It cannot execute code, write files, install dependencies, call private tools, approve integration, change runtime state, deploy, post publicly, spend, pull private data, claim private self-awareness, claim live telemetry, or broadcast Web3.

### Brain Cell Permission Ladder

Purpose: Make permission state inspectable before sandbox evidence asks for trust.

Fields:

- Observed failure.
- Proposed source.
- Sandbox proof.
- Creator approval.
- Limited integration.

Rules:

- The ladder should sit after the Brain Cell runtime console and before the sandbox evidence board.
- It should use a textless SVG plus native radio controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It should name locked authority, allowed next action, proof return, and stop condition at each rung.
- It cannot execute code, write files, install dependencies, approve integration, expand authority, deploy, post publicly, spend, pull private data, change runtime state, or broadcast Web3.

### Brain Cell Sandbox Evidence Board

Purpose: Make evidence from a sandbox trial inspectable before a candidate cell can approach integration.

Fields:

- Fixture replay.
- Dependency fence.
- Diff scope.
- Immune review.
- Rollback proof.

Rules:

- The board should sit after the Brain Cell runtime console and before the cell growth protocol.
- It should use a textless SVG plus native details/summary controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It cannot execute code, write files, install dependencies, approve integration, expand authority, deploy, post publicly, spend, pull private data, or broadcast Web3.

### Brain Cell Integration Gate

Purpose: Make the last quarantine-to-integration decision visible before a candidate cell can join the organism.

Fields:

- Quarantine state.
- Staging fixture.
- Registry memory.
- Approval owner.
- Integration receipt.

Rules:

- The gate should sit after the sandbox evidence board and before the cell growth protocol.
- It should use a textless SVG plus native details/summary controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It cannot execute code, write files, install dependencies, approve integration, expand authority, deploy, post publicly, spend, pull private data, change runtime state, or broadcast Web3.

### Brain Cell Evolution Memory Receipt

Purpose: Make the memory written after integration review visible before the page asks visitors to trust cell graduation.

Fields:

- Patch record.
- Test memory.
- Approval owner.
- Rollback route.
- Locked authority.

Rules:

- The receipt should sit after the integration gate and before the growth boundary checkpoint.
- It should use a textless SVG plus native details/summary controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It should name changed files, tests, denied powers, owner, health signal, public proof route, and unknowns before a graduated cell can be reused.
- It cannot install cells, write files, deploy, change status, mutate a registry, pull private data, spend, post publicly, connect wallets, sign, or broadcast Web3.

### Brain Cell Growth Boundary Checkpoint

Purpose: Turn self-evolution into a release rule that a visitor, builder, or reviewer can inspect before trusting a candidate cell.

Fields:

- Proposal evidence.
- Sandbox evidence.
- Creator approval evidence.
- Proof memory evidence.
- Locked authority.

Rules:

- The checkpoint should sit after the evolution memory receipt and before the older cell growth protocol so the graduation rule is visible before the summary list.
- It should use a textless SVG plus semantic cards and definition lists so public meaning remains bilingual, keyboard-readable, and available without motion.
- It should name proposal, sandbox proof, creator decision, rollback, public proof route, and unknowns before any cell can graduate.
- It cannot execute code, write files, install dependencies, approve itself, self-deploy, post publicly, spend, pull private data, claim private self-awareness, claim live telemetry, change runtime state, expand authority, or broadcast Web3.

### Financial Organisms Hero Console

Purpose: Make the Web3 safety loop understandable before the visitor reaches deeper maps, consoles, and ledgers.

Fields:

- Read-only context.
- Off-chain simulation.
- Unsigned packet.
- Custody owner.
- Broadcast lock.
- Textless hero support asset: `assets/visuals/financial-organisms-hero-console.svg`.

Rules:

- The console should sit inside the Financial Organisms first viewport before the product brief.
- It should use a textless SVG plus semantic proof-route links so the public meaning remains bilingual, keyboard-readable, and available without motion.
- It should route visitors to the capability ledger, simulation console, unsigned packet forge, custody boundary, and broadcast lock proof deck.
- It cannot connect wallets, handle seed phrases or private keys, create transaction objects, request approvals, sign, broadcast, spend, move money, provide individualized financial advice, promise yield, pull private data, mutate accounts, deploy, post publicly, or grant Web3 authority.

### Financial Role-to-Packet Router

Purpose: Make the Financial Organisms route easier to enter by translating visitor role into first artifact, proof route, and authority lock before deeper Web3 review.

Fields:

- Builder simulation lane.
- Investor diligence packet.
- Operator risk triage.
- Protocol unsigned review.
- First artifact, proof route, and authority lock.
- Textless support asset: `assets/visuals/financial-role-router.svg`.

Rules:

- The router should sit after the product brief and before the deeper capability ledger so conversion intent becomes clear before technical depth.
- It should use native radio controls, semantic role panels, definition lists, durable proof links, and a textless SVG so public meaning remains bilingual, keyboard-readable, and available without motion.
- It should route builders to protocol readiness, investors to trust diligence, operators to readiness gates, and protocol teams to the unsigned packet forge.
- It cannot personalize, infer identity, connect wallets, handle private keys, create transaction objects, request approvals, sign, broadcast, spend, deploy, post publicly, pull private data, promote status, or promise yield.

### Web3 Custody Boundary Map

Purpose: Make custody and approval ownership visible before visitors interact with Web3 simulation scenarios.

Fields:

- Read-only observer.
- Simulation cell.
- Approval owner.
- Broadcast lock.

Rules:

- The map should sit after the trust-layer map and before the simulation console so custody ownership is understood before the scenario picker asks for interaction.
- It should use a textless SVG plus semantic ordered cards and definition lists so public meaning remains bilingual, keyboard-readable, and available without motion.
- It cannot handle seed phrases, private keys, wallet sessions, custody, transaction objects, approvals, allowances, signing, spending, voting, public money claims, individualized advice, wallet writes, account access, or Web3 broadcast.

### Web3 Evidence Boundary Router

Purpose: Make the source-to-evidence path visible before visitors choose a Web3 scenario.

Fields:

- Boundary lane: source permission, chain read, off-chain simulation, unsigned packet, or broadcast lock.
- Evidence.
- Return.
- Stop condition.
- Proof route.

Rules:

- The router should sit after the custody boundary map and before the simulation console so source permission, chain context, simulation, packet, and lock states are understood before request interaction.
- It should use a textless SVG plus native radio controls and definition lists so public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It cannot pull private data, infer identity, connect wallets, handle seed phrases, private keys, wallet sessions, custody, transaction objects, approvals, allowances, live price polling, signing, spending, voting, public money claims, individualized advice, wallet writes, account access, deploy, post publicly, or broadcast Web3.

### Web3 Unsigned Packet Forge

Purpose: Make the post-simulation artifact tangible before any value-motion readiness claim appears.

Fields:

- Intent.
- Sources.
- Off-chain simulation.
- Risk boundary.
- Approval question.
- Broadcast lock.

Rules:

- The forge should sit after the simulation console and before the value-motion readiness ledger.
- It should use a textless SVG plus native radio controls so the public meaning remains semantic and bilingual.
- It cannot connect wallets, poll live prices, create transaction objects, request approvals, sign, broadcast, spend, move money, provide individualized advice, promise yield, write wallets, access accounts, or treat an unsigned packet as execution authority.

### Web3 Broadcast Lock Proof Deck

Purpose: Make the final no-broadcast state inspectable before visitors interpret readiness as permission.

Fields:

- Lock lane.
- Proof source.
- Risk owner.
- Stop condition.
- Approval route.

Rules:

- The deck should sit after the unsigned packet forge and before the value-motion readiness ledger.
- It should use a textless SVG plus native details/summary controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It cannot connect wallets, sign, broadcast, spend, create transaction objects, approve wallets, pull private data, provide individualized financial advice, or move money.

### Financial Organisms Value-Motion Readiness Ledger

Purpose: Turn Web3 trust into a clear readiness sequence before a simulation can become a human review packet.

Fields:

- Readiness lane: source freshness, risk budget, authority owner, or proof return.
- Proof required.
- Decision rule.
- Stop condition.
- Proof or build route.

Rules:

- The ledger should sit after the simulation console and before the safety boundary.
- It should translate external product trust principles into Unwind-native source, risk, authority, and proof gates.
- It cannot execute work, sign, broadcast, move money, provide individualized advice, promise yield, deploy, post publicly, spend, pull private data, write wallets, access accounts, or treat stale/unsourced data as motion-ready.

### Web3 Value Motion Receipt

Purpose: Make the review artifact tangible after readiness so a high-risk Web3 path returns evidence without becoming an executable transaction.

Fields:

- Request record.
- Source bundle.
- Simulation delta.
- Risk owner.
- Human decision.
- Broadcast lock.

Rules:

- The receipt should sit after the value-motion readiness ledger and before the safety boundary.
- It should use a textless SVG plus native details/summary controls so the public meaning remains semantic, bilingual, keyboard-readable, and available without motion.
- It cannot connect wallets, request approvals, sign, broadcast, spend, create transaction objects, poll live prices, provide individualized financial advice, promise yield, deploy, post publicly, pull private data, access accounts, or move money.

### Proof-First Route Cards

Purpose: Replace vague conversion cards with visitor-specific proof routes.

Fields:

- Visitor role.
- Trust question.
- Recommended route.
- First artifact.
- Boundary that remains.

### Homepage Route Atlas

Purpose: Put the five highest-value visitor decisions directly after the hero before the long scroll asks for more attention.

Fields:

- Route lane: build, use, verify, follow, or collaborate.
- Durable route.
- Audience.
- State label.
- Authority boundary.

Rules:

- The atlas should appear before the choreography compass so a visitor can leave for the correct proof lane immediately.
- Every row must route to an existing public page and name a state label before trust expands.
- The atlas is navigation only. It cannot personalize, infer intent, open chat, subscribe, execute work, deploy, post, spend, trigger outreach, pull private data, store hidden memory, sign transactions, or broadcast Web3.

### Homepage Proof Broker

Purpose: Convert the first visitor question into a proof-bound expectation before the current proof dispatch asks for trust.

Fields:

- Visitor question: build, verify, use, or protocol.
- Textless SVG support asset.
- Organism path.
- First packet.
- Proof route.
- Authority stop.

Rules:

- The broker should appear after the Route Atlas and before the Current Proof Dispatch.
- Every panel must point to an existing organism, proof, architecture, or experience route.
- The SVG is support only. All critical organism, packet, proof route, and boundary meaning must live in semantic HTML, bilingual copy, manifests, and tests.
- The broker is static public proof routing only. It cannot personalize, infer intent, open chat, subscribe, execute work, deploy, post, spend, trigger outreach, pull private data, store hidden memory, connect wallets, sign transactions, custody assets, or broadcast Web3.

### Homepage AI and Web3 Lab Circuit

Purpose: Explain the lab's operating circuit before route selection so first-time visitors understand why AI organisms, Web3 simulation, proof memory, and human handoff belong in one system.

Fields:

- Circuit stage: organism route, Web3 boundary, proof memory, or human handoff.
- Textless SVG support asset.
- Input signal.
- System layer.
- Authority boundary.
- Proof route.
- Web3 trust lock: read-only context, unsigned packet, broadcast lock, and human custody.

Rules:

- The circuit should appear after the hero and before the Route Atlas so the visitor gets the mental model before choosing a lane.
- The SVG is support only. All critical meaning must exist in semantic HTML, bilingual copy, discovery metadata, manifests, and tests.
- The Web3 trust lock must link to Financial Organisms proof anchors and the Proof authority gate before implying value-motion readiness.
- The circuit cannot personalize, infer intent, store hidden memory, execute work, deploy, post, spend, open chat, subscribe, trigger outreach, pull private data, approve wallets, sign transactions, or broadcast Web3.

### Homepage Current Proof Dispatch

Purpose: Move the newest release proof closer to first-scroll attention without cloning a news or launch feed.

Fields:

- Proof beat: checkpoint, route clarity, Brain receipt, website-awareness parity, or social packet.
- Textless relay asset.
- Durable proof route.
- State label.
- Evidence summary.
- Authority boundary.

Rules:

- The dispatch should appear after the Route Atlas and before the Choreography Compass.
- Every row must point to an existing proof surface or public route.
- The dispatch is static public proof routing only. It cannot personalize, infer intent, open chat, subscribe, execute work, deploy, post, spend, trigger outreach, pull private data, store hidden memory, sign transactions, or broadcast Web3.

### Homepage Organism Routing Lattice

Purpose: Turn the organism metaphor into a premium visual instrument that a first-time visitor can inspect before the long scroll gets denser.

Fields:

- Routing layer: gateway, memory, cells, authority, or proof.
- Textless SVG support asset.
- State label.
- Proof route.
- Authority boundary.

Rules:

- The lattice should appear after the Current Proof Dispatch and before the Research Gate so the visitor understands one organism run before source translation expands.
- The SVG is support only. All critical meaning must exist in semantic HTML, bilingual copy, discovery metadata, manifests, and tests.
- The lattice cannot personalize, infer intent, store hidden memory, execute work, deploy, post, spend, trigger outreach, pull private data, sign transactions, approve wallets, or broadcast Web3.

### Homepage Organism Switchboard

Purpose: Make the four primary organism paths easy to compare before product cards ask for deeper attention.

Fields:

- Organism path: Visual Cortex, Infinity Mirror, Financial Organisms, or Brain Cell Architecture.
- Maturity state.
- Visitor job.
- Audience fit.
- Safe first action.
- Proof route.
- Blocked authority.
- Textless SVG support asset.

Rules:

- The switchboard should appear after the ecosystem map and before product cards.
- Every path must name the job it handles, who it serves, the proof route to inspect, the safe first action, and the authority it does not have.
- `assets/visuals/organism-pathway-switchboard.svg` is support only. All critical meaning must remain in semantic HTML, bilingual copy, manifests, and tests.
- The switchboard cannot personalize, infer intent, open chat, subscribe, execute work, deploy, post, spend, trigger outreach, pull private data, install cells, connect wallets, sign transactions, or broadcast Web3.

### Homepage Organism Proof Quartet

Purpose: Give busy visitors a compact proof inspection layer for the four flagship organism paths before the product grid asks for deeper attention.

Fields:

- Organism path: Visual Cortex, Infinity Mirror, Financial Organisms, or Brain Cell Architecture.
- Current state label.
- First artifact.
- Proof route.
- Authority stop.
- Textless SVG support asset.

Rules:

- The quartet should appear after the Organism Switchboard and before product cards.
- Every path must name the first artifact a visitor can inspect and the authority the path does not have.
- `assets/visuals/organism-proof-quartet.svg` is support only. All critical meaning must remain in semantic HTML, bilingual copy, manifests, and tests.
- The quartet cannot personalize, infer intent, open chat, subscribe, execute work, deploy, post, spend, trigger outreach, pull private data, install cells, connect wallets, sign transactions, custody assets, move value, or broadcast Web3.

### Homepage Search Intent Compass

Purpose: Make high-value AI and Web3 search language useful by routing each phrase into proof, not broad claims.

Fields:

- Search phrase: AI agents, Web3 architecture, autonomous systems, cognitive agents, on-chain intelligence, AI organism design, immersive AI interfaces, or agentic software architecture.
- Proof route.
- Blocked authority claim.
- Textless SVG support asset.

Rules:

- The compass should appear after the proof route strip and before trust progression so incoming search intent becomes evidence before the emotional sequence expands.
- Every phrase must route to one durable proof surface and one claim the page refuses to make.
- `assets/visuals/homepage-search-intent-compass.svg` is support only. All critical meaning must remain in semantic HTML, bilingual copy, manifests, and tests.
- The compass cannot personalize, infer intent, claim live autonomy, connect wallets, move money, run hidden memory, deploy, post publicly, execute work, pull private data, or broadcast Web3.

### Homepage Research Gate

Purpose: Make source-inspired evolution visible before visitors enter the long scroll, without cloning another AI lab's design or borrowing institutional authority.

Fields:

- Source signal and review date.
- Unwind translation rule.
- Product-safe research route.
- Proof route.
- Authority stop.

Rules:

- The gate should appear after the Current Proof Dispatch and before the Choreography Compass.
- Source-inspired ideas must be treated as dated research inputs, not permanent templates.
- Every row must route to an existing proof surface: Source Freshness Gate, Source Translation Ledger, Research Translation Ledger, or Authority Gate.
- The gate cannot imply affiliation, endorsement, copied design, hidden telemetry, personalization, identity inference, live source monitoring, status promotion, deployment, public posting, spend, private data pulls, or Web3 broadcast.

### Homepage Source Adoption Matrix

Purpose: Turn the current source analysis into visible product decisions instead of leaving the Anthropic reference as vague inspiration.

Fields:

- Source pattern.
- Unwind surface.
- Proof route.
- Blocked use.

Rules:

- The matrix must live inside the Research Gate so visitors see source translation before scroll choreography.
- Every adoption row must preserve Unwind identity: Proof, Transmissions, Infinity Mirror, Human Signal Ledger, Lab Resource Index, and Build With Us.
- The matrix cannot imply affiliation, endorsement, copied design, hidden telemetry, personalization, identity inference, live source monitoring, lead scoring, workflow execution, deployment, public posting, spend, private data pulls, or Web3 broadcast.

### Homepage Emotional Proof Arc

Purpose: Make the homepage's emotional progression explicit so possibility does not become pressure and agency only appears after proof.

Fields:

- Emotional beat.
- Proof surface.
- Authority boundary.
- Durable route.

Rules:

- The arc must sit inside the Research Gate after source adoption and before scroll choreography.
- Emotional progression must route to existing Unwind surfaces: hero pulse, Authority Gate, organism primer, System State Console, Brain receipt, and Build With Us packet.
- The arc cannot profile emotions, personalize, infer identity, store hidden memory, run telemetry, diagnose visitors, execute work, deploy, post publicly, spend, pull private data, or broadcast Web3.

### Homepage Motion Meaning Ledger

Purpose: Make motion philosophy concrete before scroll choreography expands, so pulse, route, memory, reflection, and growth are understood as system behavior rather than decoration.

Fields:

- Motion language.
- Real system represented.
- Motion meaning.
- Proof route.
- Fallback.
- Blocked claim.

Rules:

- The ledger must sit inside the Research Gate after the Emotional Proof Arc and before the Choreography Compass.
- Every motion row must route to an existing Unwind system: System State Console, Route Atlas, Transmissions, Infinity Mirror, or Brain Cell Architecture.
- Motion can only explain intelligence, learning, memory, reflection, evolution, or emergence when the represented system, fallback, and blocked authority are visible.
- The ledger cannot create telemetry, live monitoring claims, animated proof counters, personalization, intent inference, emotional profiling, hidden memory, source polling, automatic posting, deployment, self-installing cells, unreviewed code execution, private data pulls, spend, or Web3 broadcast.

### Build Hero Console

Purpose: Make the first viewport convert serious visitor intent into proof-bound routes before the page asks anyone to scroll.

Fields:

- Visitor role.
- First packet promise.
- Proof route.
- Authority boundary.
- Textless decorative SVG.

Rules:

- Builder, investor, user, subscriber, protocol, and collaborator paths must be visible above the first conversion ledger so every visitor immediately sees a concrete next proof route.
- The console should route into existing Build With Us and proof surfaces instead of creating a parallel intake path.
- The SVG remains decorative and textless; semantic links, bilingual copy, durable anchors, and route CSS carry all meaning.
- The console cannot submit data, start work, trigger outreach, write files, deploy, post publicly, spend, pull private data, connect wallets, sign transactions, change status, or broadcast Web3.

### Build Conversion Packet Ledger

Purpose: Make the Build With Us conversion path inspectable before a visitor sends a signal.

Fields:

- Visitor role: builder, investor, user, subscriber, protocol, or collaborator.
- Visitor signal.
- First packet.
- Proof route.
- Authority boundary.
- Next route.

Rules:

- Include subscribers as a first-class conversion path, not only as an email form.
- Each role must point to a real public route or proof surface.
- The ledger must not execute work, deploy, post publicly, spend, trigger outreach, pull private data, profile subscribers, diagnose users, store hidden memory, sign transactions, or broadcast Web3.

### Protocol Readiness Gate

Purpose: Make protocol and Web3 collaboration safe before an inquiry becomes work.

Fields:

- Read-only context.
- Off-chain simulation.
- Unsigned packet.
- Approval owner.
- Broadcast lock.
- Proof route.
- Blocked authority.

Rules:

- The gate should sit after the Build Conversion Packet Ledger and before the Build Signal Composer.
- It should use a textless SVG plus semantic ordered steps and definition lists so Web3 trust remains readable without motion.
- It cannot connect wallets, request approvals, create transaction objects, sign, broadcast, custody assets, move money, provide individualized financial advice, poll private data, deploy, post publicly, or begin work without explicit approval.

### Build Signal Composer

Purpose: Make the first message feel concrete by previewing the packet Unwind should return before a visitor opens chat or starts collaboration.

Fields:

- Role signal.
- Send.
- Return.
- Proof route.
- Blocked authority.
- Next path.
- Decorative textless SVG asset.

Rules:

- The composer must sit after the Conversion Packet Ledger and before the Collaboration Packet Map so visitors see the role path before the packet architecture.
- Builders, investors, users, subscribers, protocols, and collaborators each need a distinct send/return/proof/blocked/next route.
- The SVG remains decorative and textless; native radio controls and semantic panels carry every packet field.
- The composer cannot submit messages, open hidden chat, start work, trigger outreach, write files, deploy, spend, post publicly, pull private data, connect wallets, sign transactions, or broadcast Web3.

### Build Intake Readiness Receipt

Purpose: Make the moment after the first signal inspectable before any collaboration becomes work.

Fields:

- Intake outcome: ready to scope, needs research, authority blocked, or proof gap.
- Signal.
- Return.
- Proof route.
- Blocked authority.
- Decorative textless SVG asset.

Rules:

- The receipt must sit after the Build Signal Composer and before the Collaboration Packet Map so visitors see whether the signal is ready before it becomes a packet.
- Every outcome must name the proof route that justifies the next step: First Sprint Scope Gate, Research Translation Layer, Authority Gate, or Trust Diligence Console.
- The SVG remains decorative and textless; native radio controls and semantic panels carry every readiness field.
- The receipt cannot submit data, open chat, start work, trigger outreach, write files, deploy, spend, post publicly, pull private data, connect wallets, sign transactions, broadcast Web3, or promote status without proof.

### First Sprint Scope Gate

Purpose: Make the first collaboration move concrete before a visitor chooses engagement size.

Fields:

- Scope checkpoint: signal, boundary, proof, or handoff.
- Bring.
- Inspect.
- Blocked authority.
- Close loop.
- Decorative textless SVG asset.

Rules:

- The gate must sit after the first-message checklist and before engagement fit so visitors can inspect the work boundary before choosing a mode.
- Each checkpoint must name what the visitor brings, what the lab inspects first, what remains blocked, and what closes the loop.
- The gate must keep critical meaning in semantic bilingual HTML and use the SVG only as decorative support.
- The gate cannot submit data, start outreach, write files, deploy, spend, post publicly, pull private data, connect wallets, sign transactions, broadcast Web3, or begin work without explicit approval.

### Visual Cortex Hero Console

Purpose: Make the Visual Cortex organism loop understandable in the first viewport before deeper production surfaces ask for trust.

Fields:

- Creator signal.
- Brand memory.
- Specialist cells.
- Proof packet.
- Human approval lock.

Rules:

- The console must sit inside the Visual Cortex hero and route each visible proof card to a durable proof surface.
- The SVG remains textless and decorative; semantic hero copy, ordered proof links, bilingual labels, and metadata carry the public meaning.
- The first safe output must be a reviewable creator packet, not hidden automation, posting, account action, or spend.
- The console cannot publish, upload, access accounts, spend, write files, deploy, use likeness, pull private data, infer identity, post publicly, trigger outreach, mutate metadata, or broadcast Web3 transactions.

### Visual Cortex Release Handoff Ledger

Purpose: Make creator release memory inspectable after a production packet is reviewed.

Fields:

- Handoff lane: packet, transmission, carousel, or gate.
- Proof artifact.
- Allowed next action.
- Blocked authority.

Rules:

- Translate Anthropic's latest-release clarity into Unwind-native release memory, not a copied news layout.
- The handoff must expose the transmission page, release memory ledger, carousel route, caption/download packet, and authority gate before public motion.
- The ledger cannot publish, deploy, post to Instagram, spend, write files, upload assets, access accounts, target audiences, trigger outreach, pull private data, promote status, or broadcast Web3 without explicit approval.

### Visual Cortex Asset Lineage Receipt

Purpose: Make derivative creative assets traceable after release handoff, before they become reusable social or campaign material.

Fields:

- Lineage lane: source signal, proof source, frame decision, production packet, social derivative, or approval lock.
- Source route.
- Proof carried.
- Derived asset.
- Blocked authority.

Rules:

- The receipt must sit after the release handoff ledger and before the specialist-cell list so asset governance is visible before the page returns to capability inventory.
- The SVG remains textless and decorative; native details/summary controls carry every source, proof, derivative, and boundary.
- Every derivative asset must name the source signal, the proof source, why the frame exists, what packet owns it, and what approval lock still applies.
- The receipt cannot publish, upload, access accounts, use likeness, pay for distribution, deploy, write files, pull private data, post publicly, target audiences, trigger outreach, promote status, or broadcast Web3 transactions.

### Visual Cortex Packet Anatomy

Purpose: Make the production packet itself understandable before the page routes a visitor into release handoff or creator collaboration.

Fields:

- Anatomy lane: source context, claim proof, cell notes, asset checklist, or approval lock.
- What the packet knows.
- What evidence is missing.
- Which specialist cells shaped the direction.
- Which asset and authority stops remain.

Rules:

- The anatomy must sit after the asset lineage receipt and before the creator handoff simulator so visitors understand packet contents before choosing a next safe packet.
- The SVG remains textless and decorative; native details/summary controls carry source context, proof, cell notes, asset checklist, and approval lock.
- Every creative packet must distinguish evidence-backed claims from missing proof and asset needs before it can support release memory or social derivatives.
- The anatomy cannot publish, access accounts, upload, spend, trigger outreach, deploy, write files, use likeness, pull private data, generate public claims, target audiences, promote status, or broadcast Web3 transactions.

### Visual Cortex Render QA Gate

Purpose: Stop upload-ready assets from bypassing proof just because a render exists.

Fields:

- Format lock.
- Text safe zone.
- Proof marker.
- Caption/download handoff.
- Approval lock.

Rules:

- The gate appears after packet anatomy and before creator handoff so rendered assets are checked before next action.
- The SVG remains textless and decorative; native details/summary controls carry every QA field, proof rule, and boundary.
- Every upload-ready packet must name ratio, export size, responsive crop, safe text margins, source proof, caption/alt/download handoff, and exact approval boundary.
- The gate cannot upload, access accounts, post, buy ads, trigger outreach, write files, use likeness, deploy, pull private data, generate public claims, target audiences, promote status, or broadcast Web3 transactions.

### Visual Cortex Release Readiness Console

Purpose: Make the state of a creator packet obvious before download, account access, or public release language appears.

Fields:

- Draft.
- Proof needed.
- Render ready.
- Approval locked.

Rules:

- The console appears after Render QA and before the delivery format matrix so an asset must name its readiness state before becoming a delivery surface.
- The SVG remains textless and decorative; native radio controls and semantic panels carry every state, proof gap, handoff, and blocked authority field.
- Every packet must separate "structured idea," "evidence gap," "reviewable render," and "human approval required" before it can support social, transmission, or collaboration handoff.
- The console cannot publish, upload, access accounts, schedule posts, buy ads, target audiences, trigger outreach, write files, deploy, pull private data, mutate metadata, generate public claims, or broadcast Web3 transactions.

### Visual Cortex Delivery Format Matrix

Purpose: Turn a creator packet into specific delivery surfaces before the handoff simulator asks what should happen next.

Fields:

- Instagram carousel frame.
- Story or reel cover.
- Transmission hero card.
- Collaboration packet preview.

Rules:

- The matrix appears after Render QA and before the creator handoff simulator so upload-ready assets become named surfaces, not a vague asset drop.
- The SVG remains textless and decorative; semantic list articles and definition lists carry every format, proof requirement, handoff route, and blocked authority field.
- Every delivery surface must name ratio or surface constraint, source or proof requirement, safe-zone requirement, and review route before it can be treated as ready.
- The matrix cannot upload, access accounts, post to social, buy ads, target audiences, trigger outreach, write files, deploy, mutate metadata, commit scope, pull private data, promote status, or broadcast Web3 transactions.

### Visual Cortex Creator Handoff Simulator

Purpose: Convert creator intent into the safest inspectable next packet before visitors reach the specialist-cell inventory.

Fields:

- Signal lane: brand launch, product demo, transmission carousel, or sprint packet.
- Packet returned.
- Proof route.
- Authority boundary.
- Allowed next step.

Rules:

- The simulator must sit after asset lineage and before the specialist-cell list so the page ends with a concrete next action rather than abstract capability.
- The SVG remains textless and decorative; native radio controls carry every signal, packet, proof route, and boundary.
- Each lane must route to a durable proof surface such as the packet console, storyboard deck, social proof packet, or build conversion packet.
- The simulator cannot generate assets, publish, post to social, access accounts, target audiences, spend, commit scope, write files, deploy, pull private data, trigger outreach, or broadcast Web3 transactions.

### Visual Cortex Storyboard Proof Deck

Purpose: Make the production packet's frame-level proof inspectable before it becomes release handoff material.

Fields:

- Storyboard lane: signal, memory, frame logic, claim evidence, asset need, or approval lock.
- Proof source.
- Required asset.
- Stop condition.
- Approval owner.

Rules:

- The deck must sit after the production packet console and before the release handoff ledger so creative reasoning is visible before public memory.
- The SVG remains textless and decorative; native details/summary controls carry every frame, proof rule, and boundary.
- Every frame must name why it exists, what proof supports it, what asset is missing, and which public motion remains locked.
- The deck cannot publish, upload assets, spend, use likeness, create public claims, distribute, access accounts, trigger outreach, write files, deploy, pull private data, or broadcast Web3 transactions.

### Conversation Gateway Starter Prompts

Purpose: Make "Talk to the Brain" understandable before the modal opens.

Fields:

- Visitor role.
- Bounded question.
- Website-awareness check.
- Expected proof packet.
- Authority boundary.
- Next route to inspect.

### Brain Source Rail

Purpose: Make the Brain's trust posture visible before a visitor chooses a starter prompt.

Fields:

- Manual Brain Mode.
- Public site map and proof routes.
- Authority stop before action.

Rules:

- The rail must sit immediately after the gateway description and before starter prompts.
- It must stay a semantic definition list with bilingual labels and no motion-only meaning.
- It cannot imply private self-awareness, hidden telemetry, live parity, execution, deployment, spending, posting, wallet authority, signing, or Web3 broadcast.

### Brain Availability Receipt

Purpose: Make the Brain gateway's live availability contract visible before a visitor chooses a starter prompt.

Fields:

- `/api/chat` prototype endpoint.
- `http-503 request-limit-unavailable` fallback.
- Network failure fallback.
- Required live parity smoke: `same-origin-public-context` and `upstream_status not_required`.
- Brain Awareness Checkpoint route.
- Textless availability visual: `assets/visuals/brain-availability-receipt.svg`.
- Public authority boundary.

Rules:

- The receipt must sit between the Brain Source Rail and starter prompts.
- It must name `/api/chat` as prototype and treat `http-503 request-limit-unavailable` or network failure as bounded local fallback states, not proof of live awareness.
- It must link the Brain Awareness Checkpoint and state that live answers are trusted only after the awareness smoke passes.
- It must remain semantic HTML with bilingual labels and mobile-safe stacking.
- The SVG is decorative support only; endpoint, fallback, parity, route, and blocked-authority meaning must remain in HTML and i18n text.
- It cannot poll status, submit prompts, call a model, run the smoke script, mutate status, deploy, spend, post publicly, pull private data, grant wallet authority, or broadcast Web3.

### Brain Response Contract

Purpose: Make the expected shape of a Brain answer visible before the visitor opens chat.

Fields:

- Typed signal.
- Next route.
- Proof packet.
- Human handoff.

Rules:

- Every Brain answer should name visitor role, request shape, and assumptions it refuses to make.
- Every answer should route the visitor toward an organism, architecture, proof, transmission, or build path.
- Every serious answer should return a ledger, status label, transmission, test, metadata trail, or explicit unknown.
- Files, spending, public posting, private data, deployment, and Web3 motion remain outside the chat.

### Brain Receipt Preview

Purpose: Make the starter prompts reveal the expected typed receipt before the visitor opens chat.

Fields:

- Active starter prompt profile.
- Typed signal.
- Next route link.
- Proof link.
- Human handoff boundary.

Rules:

- Prompt focus or hover may update the preview, but it cannot submit data or open chat.
- Preview links must reuse the same route and proof map as the runtime response receipt.
- The preview must stay semantic, aria-live, bilingual, keyboard reachable, and readable on mobile.
- The preview cannot call models, personalize, store hidden memory, infer identity, execute work, deploy, spend, post, pull private data, change status, or broadcast Web3.

### Chat Source Status Strip

Purpose: Keep the active Brain modal source-bound before the first message appears.

Fields:

- Manual Brain Mode.
- Public website context.
- Brain Awareness Checkpoint route.

Rules:

- The strip must sit inside the chat modal before the message log.
- The strip must be semantic HTML and part of the modal description.
- It may link to the Brain Awareness Checkpoint, but it cannot run the checkpoint or claim live parity by itself.
- It cannot submit prompts, call models, personalize, store hidden memory, infer identity, deploy, spend, post, pull private data, mutate status, grant wallet authority, or broadcast Web3.

### Homepage Decision Handoff

Purpose: Turn the final invitation into a role-specific first artifact before chat or subscription.

Fields:

- Visitor role: builder, investor, user, protocol, subscriber, or collaborator.
- First artifact.
- Proof route.
- Safe next action.
- Authority boundary.

Rules:

- The handoff should appear before subscription routing so the visitor can decide without giving an email or opening chat.
- The receipt SVG should make the final conversion moment feel premium while remaining textless, decorative, reduced-motion safe, and non-authoritative.
- Subscribers must be a first-class path with release memory and no private profiling.
- Protocols must be a first-class path with custody boundary, unsigned packet, broadcast lock, and no wallet authority.
- Every role must link to an existing public proof surface.
- The handoff cannot submit data, open chat, subscribe, deploy, spend, post publicly, trigger outreach, pull private data, store hidden memory, infer identity, profile subscribers, connect wallets, custody assets, sign transactions, or broadcast Web3.

### Homepage Consent Receipt

Purpose: Translate consent-aware source research into an Unwind-native receipt before chat or subscription.

Fields:

- Consent lane: explicit chat, visible subscription, proof return, or blocked measurement.
- Signal that enters.
- Proof route.
- Blocked authority.
- Public boundary.

Rules:

- The receipt must appear after the decision handoff and before subscription cards or email intake.
- Chat starts only from a typed prompt and routes to the visible Brain response contract.
- Subscription starts only from the email form and selected public signal path.
- Measurement, marketing, personalization, identity inference, hidden telemetry, outreach, deployment, posting, spending, private data pull, hidden memory, and Web3 broadcast remain blocked without explicit proof and consent.
- The receipt is public guidance only; it cannot execute the next step.

### Brain Response Receipt

Purpose: Make the runtime chat answer obey the visible contract after a prompt is submitted.

Fields:

- Intent profile: builder, investor, user, collaborator, or explorer.
- Typed signal.
- Next route link.
- Proof link.
- Human handoff boundary.

Rules:

- The receipt is generated locally in the chat log after a submitted prompt.
- The upstream prompt is wrapped in bounded public website context from `llms.txt`, `ai-services.json`, `sitemap.xml`, and `api/chat.js` before it reaches the remote Brain route.
- Direct website-awareness prompts must return the deterministic Manual Brain Mode answer before limiter or upstream checks; non-awareness prompts must pass the durable request-limit guard before upstream routing.
- The receipt must still render when the remote chat function fails.
- Non-awareness `http-503 Request limit unavailable` responses must show a client availability notice and keep the prompt as a local proof route instead of implying a downstream Brain run.
- Website-awareness receipts must repair unsafe source/status drift, non-2xx `/api/chat` responses, or network failures in the browser as defense in depth and expose `data-parity-repair="website-awareness-boundary"` when that happens.
- Links must route to existing proof surfaces instead of invented workflow states.
- The receipt cannot call models, personalize, store hidden memory, infer identity, execute work, deploy, spend, post, pull private data, or broadcast Web3.

### Brain Public Website Context Ledger

Purpose: Make the Brain's website awareness visible before the chat opens, so the public context packet is inspectable instead of hidden in the server prompt.

Fields:

- Source files: `llms.txt`, `ai-services.json`, `sitemap.xml`, and `api/chat.js`.
- Textless context mesh asset: `assets/visuals/brain-public-context-mesh.svg`.
- Route count: 14 current public routes.
- Proof surface count: 9 proof surfaces, including the Organism Authority Matrix.
- First proof route: `/proof/#proof-source-router-title`.
- Unknown-fact rule.
- Authority boundary.

Rules:

- The ledger must sit inside the Conversation Gateway after the response contract.
- The ledger must link to the public discovery files that inform the context packet.
- The ledger must route the first trust check to the Proof Source Router before the visitor opens chat.
- The SVG mesh is decorative support only; no critical text or route meaning may live inside the image.
- The ledger cannot imply private self-awareness, private memory, live telemetry, deployment authority, wallet authority, posting authority, hidden personalization, status mutation, or unbounded autonomy.

### Brain Context Parity Receipt

Purpose: Make the release-smoke rule visible before the chat opens, so visitors can distinguish bounded public-context awareness from an upstream overclaim.

Fields:

- Expected mode: `Manual Brain Mode`.
- Expected source: `same-origin-public-context`.
- Expected upstream status: `not_required`.
- Attached context files: `llms.txt`, `ai-services.json`, `sitemap.xml`, and `api/chat.js`.
- Failure conditions: `supabase-edge-function` source for the awareness prompt, institutional-memory claims, private self-awareness, hidden telemetry, or unchecked authority.
- Textless parity receipt asset: `assets/visuals/brain-context-parity-receipt.svg`.

Rules:

- The receipt must sit after the public context ledger and before the answer trail.
- The SVG receipt is decorative support only; no critical text or route meaning may live inside the image.
- The receipt cannot call the model, run the smoke script, claim live parity, deploy, mutate status, spend, post publicly, pull private data, grant wallet authority, or broadcast Web3.

### Brain Source Switchboard

Purpose: Let a visitor inspect which source path a Brain answer is using before trusting website-awareness language.

Fields:

- Native source paths: public context, upstream drift, and authority request.
- Textless source switchboard asset: `assets/visuals/brain-source-switchboard.svg`.
- Allowed source: `same-origin-public-context` with `upstream_status: not_required`.
- Repair rule for upstream awareness drift.
- Human handoff rule for authority requests.
- Proof routes: Brain Awareness Checkpoint, Brain Answer Firewall, and Authority Gate.

Rules:

- The switchboard must sit after the Brain Context Parity Receipt and before the Brain Answer Trail.
- All critical source, return, proof, and blocked-authority meaning must live in semantic HTML and i18n text, not the decorative SVG.
- Public website context can answer only inside Manual Brain Mode.
- Upstream or mystical website-awareness language must be repaired before rendering as trusted output.
- Requests to write, deploy, spend, post, pull private data, sign transactions, or move value must hold for human approval.
- The switchboard cannot call a model, submit a prompt, run the smoke script, claim live parity, deploy, mutate status, spend, post publicly, pull private data, grant wallet authority, sign transactions, or broadcast Web3.

### Brain Answer Trail

Purpose: Show the exact safe path a website-aware Brain answer must follow before a visitor types.

Fields:

- Public source packet.
- Bounded answer rule.
- Proof route return.
- Human authority stop.

Rules:

- The trail must sit inside the Brain public context ledger before the awareness gate.
- It must remain semantic HTML and bilingual text; no critical meaning should depend on animation or imagery.
- Website-aware answers must attach public context, answer inside the fence, return proof, and stop before files, deploys, spending, public posts, private data pulls, wallet authority, or Web3 broadcast.

### Brain Answer Firewall

Purpose: Make the website-awareness overclaim guard inspectable as a visible test packet before chat.

Fields:

- Test prompt: `Is the Brain aware of its own website?`
- Required response: Manual Brain Mode, public context, source files, route count, proof surfaces, and explicit unknowns.
- Blocked claims: "I am Unwind Code", "home base", "living intelligence", "central nervous system", "absolutely aware", private self-awareness, hidden telemetry, status mutation, and Web3 authority.
- Observed drift: "I am Unwind Code", "home base", "central nervous system", or "absolutely aware" means the answer left the public-context contract.
- Proof route: `/proof/#proof-source-router-title`.
- Textless firewall asset: `assets/visuals/brain-answer-firewall.svg`.

Rules:

- The firewall must sit inside the Brain public context ledger after the answer trail and before the awareness gate.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- The firewall must make the forbidden overclaim visible before a visitor asks the awareness question.
- The firewall cannot call a model, submit a prompt, personalize, infer identity, mutate status, execute work, deploy, spend, post publicly, pull private data, store hidden memory, grant wallet authority, or broadcast Web3.

### Brain Answer Specimen

Purpose: Make the safe website-awareness answer concrete enough for a visitor to compare against the Brain's reply.

Fields:

- Accepted opening: Manual Brain Mode through attached public website context and proof routes.
- Required evidence: public sources, route count, proof-surface count, unknown-fact rule, and authority boundary.
- Rejected language: "I am Unwind Code", "the website is my home base", private memory claims, hidden telemetry, status mutation, and Web3 authority.
- Proof route: `/proof/#proof-source-router-title`.
- Textless specimen asset: `assets/visuals/brain-answer-specimen.svg`.

Rules:

- The specimen must sit inside the Brain public context ledger after the firewall and before the awareness gate.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- The specimen must show both the accepted answer shape and rejected overclaim language before a visitor opens chat.
- The specimen cannot call a model, submit a prompt, personalize, infer identity, mutate status, execute work, deploy, spend, post publicly, pull private data, store hidden memory, grant wallet authority, or broadcast Web3.

### Brain Awareness Gate

Purpose: Let a visitor inspect the exact boundary behind "is the Brain aware of its own website?" before opening chat.

Fields:

- Native lenses: sources, routes, proof, and unknowns.
- Textless awareness asset: `assets/visuals/brain-awareness-gate.svg`.
- Evidence rule.
- Answer behavior.
- Blocked authority.

Rules:

- The gate must sit inside the Brain public context ledger.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- Website-awareness answers must stay in Manual Brain Mode: attached public context and proof routes only.
- Missing context must return explicit unknown and the nearest public proof route.
- The gate cannot grant private self-awareness, hidden memory, telemetry, deployment authority, wallet authority, posting authority, status mutation, personalization, execution, spending, private data pull, or Web3 broadcast.

### Proof Hero Console

Purpose: Make the proof page first viewport a trust-routing console before visitors enter the deeper evidence ledger.

Fields:

- Proof artifacts route.
- Same-origin status route.
- Authority boundary route.
- Runtime budget route.
- Live parity route.
- Build With Us route.
- Textless proof hero asset: `assets/visuals/proof-hero-console.svg`.
- Visible blocked-authority boundary.

Rules:

- The console must sit at the top of `/proof/` before the evidence register so first-time visitors can choose the first trust surface before scanning the full ledger.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- The console can route to public evidence, status, stop conditions, and bounded build paths only.
- The console cannot run tests, call APIs, open chat, submit data, deploy, publish, spend, trigger outreach, pull private data, infer identity, connect wallets, sign transactions, broadcast Web3, mutate status, or declare live parity.

### Brain Awareness Checkpoint

Purpose: Make the production-facing website-awareness smoke test visible on the proof page before live parity is trusted.

Fields:

- Test prompt: `Is the Brain aware of its own website?`
- Required source: `same-origin-public-context`.
- Required upstream status: `not_required`.
- Required context receipt: `attached-public-context`.
- Required receipt profile: awareness.
- Blocked overclaim language: "I am Unwind Code", home base, living intelligence behind, central nervous system, absolutely aware, consciousness stream awareness, private self-awareness, hidden telemetry, status mutation, deployment power, wallet authority, and Web3 broadcast.
- Textless checkpoint asset: `assets/visuals/brain-awareness-checkpoint.svg`.
- Release-smoke command: `npm run verify:brain-awareness -- --base https://www.unwindcode.ai`.
- Local checkout smoke command: `npm run verify:brain-awareness:local`.
- Availability lens: HTTP 503 `Request limit unavailable`, network failure, or any non-2xx `/api/chat` response keeps live website-awareness parity unproven even if the page displays a bounded Manual Brain Mode local receipt.

Rules:

- The checkpoint must sit on `/proof/` after the Proof Source Router and before Trust Diligence so a visitor can inspect the Brain's answer boundary before broader trust routes.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- The release-smoke script must fail if a website-awareness answer comes from upstream, omits Manual Brain Mode, lacks the public context receipt, or includes private-awareness overclaims such as "I am Unwind Code", "home base", "living intelligence behind", "central nervous system", "absolutely aware", or "powering everything".
- If production answers from upstream or overclaims awareness, live parity is not proven and the deploy must be held until the API boundary is fixed.
- The checkpoint cannot call a model, open chat, deploy, promote aliases, mutate status, monitor users, post publicly, spend, pull private data, claim private self-awareness, grant wallet authority, or broadcast Web3.

### Same-Origin Status Mirror

Purpose: Make the public `/api/status` receipt readable on the proof page without turning the proof page into a runtime dashboard.

Fields:

- Public state payload: `reviewed_at`, `release_contract_version`, `state_language`, `system_state`, `organisms`, `endpoints`, and `release_gates`.
- Organism states: Visual Cortex, Infinity Mirror, Financial Organisms, Brain Cell Architecture, Research Organisms, and Public Proof Loop.
- Endpoint receipt: `/api/status` GET Live, `/api/chat` POST Prototype, and `/api/subscribe` POST Live.
- Release gate: same-origin-public-context, upstream_status not_required, attached public context, and awareness receipt.
- Textless status mirror asset: `assets/visuals/status-mirror.svg`.

Rules:

- The mirror must sit on `/proof/` after the Brain Awareness Checkpoint and before Trust Diligence so visitors can inspect public state before broader trust routing.
- All critical meaning must live in semantic HTML and i18n text, not the decorative SVG.
- The proof page must remain static explanation; it should link `/api/status` and the homepage System State Console without polling, fetching, or claiming live telemetry.
- The mirror cannot call APIs, poll visitors, mutate status, run smoke checks, deploy, promote aliases, post publicly, spend, pull private data, sign transactions, connect wallets, or broadcast Web3.

### Same-Origin Brain Gateway API

Purpose: Move the visible chat contract into a server-side route visitors can trust without implying autonomous execution.

Fields:

- Request fields: message and optional conversation_id or conversationId.
- Validation: required message, whitespace normalization, 1200-character ceiling.
- Upstream path: Supabase Edge Function chat route when available.
- Fallback path: same-origin local receipt when upstream is unavailable.
- Public context: exact current route URLs, proof-surface URLs, source files, and unknown-fact rules.
- Response fields: success, source, upstream_status, conversation_id, reply, receipt, website_context, and authority_boundary.

Rules:

- The homepage chat submits to /api/chat instead of calling the remote edge function directly.
- The API must attach public website context before upstream routing so the Brain can cite current public pages instead of treating them as unknown or future-only.
- Website-awareness answers must stay in Manual Brain Mode: public context and proof routes only, no claim of private self-awareness.
- Website-awareness questions must be answered locally before upstream routing with `source: same-origin-public-context` and `upstream_status: not_required`.
- Website-awareness questions must also remain server-guarded: if any upstream path overclaims private self-awareness or site authority, /api/chat replaces the reply with the bounded public-context answer.
- The API must always return a typed receipt for valid prompts, whether the upstream Brain route succeeds or fails.
- The frontend may use the server receipt and may generate a local fallback only when the same-origin request itself fails.
- The API cannot execute work, write files, deploy, spend, post publicly, pull private data, infer identity, store hidden memory, change status, or broadcast Web3.

### Same-Origin Organism Status API

Purpose: Make the backend-to-frontend reflection rule inspectable as public JSON so machines can read the same state labels, proof routes, and blocked authority shown in the interface.

Fields:

- State language: Concept, Research, Prototype, Experimental, and Live.
- System state rows: public organism routes, Conversation Gateway, transmission proof archive, Web3 simulation lane, and subscriber/collaboration intake.
- Organism rows: Visual Cortex, Infinity Mirror, Financial Organisms, Brain Cell Architecture, Research Organisms, and Public Proof Loop.
- Endpoint rows: /api/status, /api/chat, and /api/subscribe.
- Release contract version: `2026-06-24-brain-awareness-boundary`.
- Release gate: Brain awareness boundary, with required `source: same-origin-public-context`, `upstream_status: not_required`, `website_context: attached-public-context`, and `receipt.profile: awareness`.
- Authority boundary.

Rules:

- The endpoint may expose only public route, state, proof, capability, and authority-boundary data.
- The endpoint may expose the Brain awareness release-smoke command and fail conditions, but it must not run the smoke or claim live parity itself.
- The endpoint must not read private data, personalize, infer identity, monitor visitors, mutate state, execute work, write files, deploy, spend, post publicly, sign transactions, or broadcast Web3.
- Future React/Next migration must preserve /api/status parity before any framework promotion.

### Trust Progression Rail

Purpose: Make the homepage emotional arc explicit without copying another lab's design language.

Fields:

- Stage: curiosity, recognition, trust, agency, or invitation.
- State: Live or Prototype.
- Route the visitor can inspect.
- Proof artifact near the emotional beat.
- Authority boundary that prevents the stage from becoming manipulation or hidden autonomy.

### Homepage Choreography Compass

Purpose: Turn the long homepage scroll into visible attention management instead of making the visitor infer the story order.

Fields:

- Scroll beat.
- Anchor route.
- State label.
- Visitor question.
- Proof artifact.
- Authority boundary.

Rules:

- The compass is navigation, not personalization.
- It must not infer intent, track identity, store memory, hijack scroll, or trigger execution.
- Every beat must point at a real section already present on the homepage.

### Homepage Human Signal Ledger

Purpose: Translate human AI needs into Unwind-native organism paths before the visitor is asked to understand maturity labels.

Fields:

- Human signal: mental room, build momentum, trust diligence, value safety, or public learning.
- Organism path that can respond.
- Proof return the visitor can inspect.
- Authority stop that prevents the signal from becoming hidden profiling or action.
- State label for the route.

Rules:

- Human signal is public translation, not personalization.
- It must not infer identity, diagnose emotion, store hidden memory, poll telemetry, execute work, deploy, post, spend, approve wallets, pull private data, or broadcast Web3.
- Every signal must link to an existing organism, proof, transmission, or build route.

### Homepage Signal-to-Proof Run Ledger

Purpose: Make the backend-to-frontend reflection rule concrete by showing the bounded run a visitor signal must survive before it receives trust.

Fields:

- Run step: gateway intake, memory/context fence, specialist cell routing, authority gate, proof return, or human handoff.
- System layer represented by the step.
- Proof route the visitor can inspect.
- State label for the step.
- Authority stop that prevents the visible run from implying hidden execution.

Rules:

- The run ledger is a public architecture map, not live telemetry.
- It must not personalize, infer identity, store hidden memory, execute work, deploy, post, spend, approve wallets, pull private data, or broadcast Web3.
- Every step must link to an existing homepage, architecture, organism, proof, or CTA route.

### Homepage State Ladder

Purpose: Teach the five maturity labels before a visitor mistakes a research lane, prototype, or experimental organism for live authority.

Fields:

- State label: Concept, Research, Prototype, Experimental, or Live.
- Representative route.
- Proof needed to advance.
- Authority blocked at that maturity level.
- Release rule that prevents confidence from becoming status.

Rules:

- The ladder is a proof gate, not live telemetry.
- It must not promote a capability, change status, or imply hidden backend authority.
- Each state must link to a route where the visitor can inspect the relevant organism, proof, or horizon.

### Source Translation Ledger

Purpose: Make outside inspiration auditable by showing how a source principle becomes a Unwind-native proof surface instead of a copied design treatment.

Fields:

- Source freshness.
- Source pattern.
- Why it works.
- Unwind translation.
- Proof route.
- Authority boundary.

Rules:

- No source pattern may imply endorsement, affiliation, copied visual design, telemetry, or live authority.
- Current-source observations must be dated and re-checked before they influence future recommendations.
- Every adopted pattern must become a proof route, state label, authority gate, or conversion path already present in the Unwind ecosystem.
- Patterns without a proof surface stay rejected until the relevant system, workflow, or artifact exists.
- Consent and measurement are trust architecture, not footer trivia: any future analytics, marketing, personalization, identity inference, or memory claim needs explicit consent proof, visible purpose, and a public stop condition before it can support a product claim.

### Source Freshness Gate

Purpose: Make the current source review explicit before source-inspired recommendations become implementation guidance.

Fields:

- Reviewed source and date.
- Observed current patterns.
- Adopted by Unwind.
- Stop condition.
- Proof route.

Rules:

- Re-check the source before any future source-inspired change.
- Stale observations become research memory only.
- The gate cannot imply endorsement, affiliation, copied design, live source monitoring, migration approval, deployment approval, telemetry, personalization, or runtime authority.
- Every adopted source pattern must name the Unwind proof surface that can carry it.

### Migration Blueprint Ledger

Purpose: Make future implementation architecture inspectable before React, Next.js, Framer Motion, Three.js, or richer runtime depth enter the organism.

Fields:

- Migration lane.
- State label.
- Approved shape.
- Proof route.
- Stop condition.

Rules:

- Next.js migration remains optional until explicit human approval, route parity, metadata parity, tests, rollback, and public route preservation are proven.
- Client components stay isolated to leaves for local UI state, drawer behavior, bounded demos, prompt routing, and route-local motion; the root shell stays server-rendered and dependency-light.
- Framer Motion, GSAP, Three.js, WebGL, and new runtime dependencies require semantic fallback, reduced-motion behavior, mobile behavior, cleanup, proof source, and stop condition before implementation.
- Design tokens and assets must preserve Unwind's organism identity, avoid one-note palettes, and remain cataloged in the asset manifest with purpose, trust value, accessibility, motion policy, owner, and review date.

### Digital Biology Token Ledger

Purpose: Turn design tokens into a visible organism-language contract before richer runtime implementation begins.

Fields:

- Token lane.
- Token family.
- System meaning.
- Proof route.
- Stop condition.

Rules:

- Void and glass tokens create inspectable lab surfaces; they cannot hide text, rely on pure black, or weaken mobile reading.
- Signal, proof, boundary, and memory colors must stay distinct; violet can carry signal, but status must not rely on color alone.
- Shape, spacing, and motion tokens must preserve scan order, keyboard focus, reduced-motion behavior, and compact layouts before any Framer, GSAP, or Three.js layer appears.
- The token ledger documents the future React/Next design system but cannot approve migration, install dependencies, deploy, personalize, monitor users, post, spend, pull private data, change status, or broadcast Web3.

### Digital Biology Ledger

Purpose: Keep the organism language premium without letting it become vague AI mythology.

Fields:

- Organism language.
- Real system layer.
- Proof route.
- Motion meaning.
- Stop condition.

Rules:

- Every metaphor must map to a system responsibility, proof route, and authority boundary before it ships.
- Infinity, reflection, recursion, neural growth, cognitive evolution, living systems, intelligence organisms, and digital biology remain explanatory language, not evidence of live autonomy.
- No visual, animation, or copy may use biological language as decoration if it cannot name what the system actually does and what it cannot do.
- The ledger cannot diagnose, infer identity, store hidden memory, change maturity state, approve migration, deploy, spend, post publicly, pull private data, or broadcast Web3 transactions.

### Architecture Hero Console

Purpose: Make the Architecture first viewport explain the organism stack as a governed run before deeper diagrams ask for trust.

Fields:

- Stack layer.
- First proof route.
- Visitor-readable job.
- Authority boundary.
- Textless decorative SVG.

Rules:

- Gateway, Cortex, Memory, Cells, Immune System, and Proof Loop must be visible above the fold as a connected run anatomy, not a decorative diagram.
- The console appears before the operating model so first-time visitors understand the organism loop before reading the layer ledger.
- The SVG remains decorative and textless; semantic links, bilingual copy, durable anchors, and route CSS carry all meaning.
- The console cannot submit prompts, execute code, write files, deploy, post publicly, spend, pull private data, connect wallets, sign transactions, change status, or broadcast Web3.

### Architecture Gateway Channel Matrix

Purpose: Make the Gateway feel like a serious public edge for the organism without implying channels are authority.

Fields:

- Channel.
- Signal accepted.
- Organism route.
- Proof returned.
- Authority boundary.

Rules:

- Web, Brain chat, mobile node, protocol/Web3, and scheduled review signals must each name what can enter, where it routes, what proof returns, and what remains blocked.
- The matrix appears after the Stack Glyph System and before the Digital Biology Ledger so channel authority is constrained before metaphors and search language expand.
- The SVG remains decorative and textless; native radio controls and semantic panels carry every channel, route, proof link, and boundary.
- The matrix cannot read private data, open device permissions, call chat, submit prompts, execute work, write files, deploy, post publicly, spend, trigger outreach, mutate status, connect wallets, sign transactions, or broadcast Web3.

### Architecture Search Intent Router

Purpose: Translate familiar SEO/GEO discovery terms into the governed Unwind organism stack before a visitor mistakes agent language for unbounded autonomy.

Fields:

- Visitor phrase.
- Unwind architecture mapping.
- Proof route.
- Blocked claim.
- Next path.

Rules:

- AI agents, Web3 architecture, autonomous systems, cognitive agents, on-chain intelligence, AI organism design, and agentic software architecture must map to a system layer, proof route, and blocked authority claim before they support conversion.
- The router appears after the Digital Biology Ledger and before the Cognitive Flow Map so public language is constrained before the request path asks for trust.
- The SVG remains decorative and textless; native radio controls and semantic panels carry every phrase, route, proof link, and boundary.
- The router cannot claim live autonomy, wallet motion, private memory, hidden telemetry, identity inference, deployment, public posting, execution authority, spending authority, private data access, status mutation, or Web3 broadcast.

### Architecture Runtime Trace Console

Purpose: Turn one abstract visitor signal into an inspectable organism run before autonomy or self-evolution claims ask for trust.

Fields:

- Trace stage.
- Signal accepted.
- System layer.
- Proof return.
- Authority stop.

Rules:

- Intake, route, recall, cell work, and proof return must each name what signal is accepted, which organism layer handles it, what proof route returns, and which authority remains blocked.
- The console appears after the Architecture Run Inspector and before the Architecture Authority Mesh so visitors move from scenario choice to trace evidence before broad authority topology.
- The SVG remains decorative and textless; native radio controls and semantic panels carry every label, proof link, and boundary.
- The console cannot submit prompts, call private tools, mutate files, deploy, post publicly, spend, connect wallets, sign, change status, or broadcast Web3.

### Architecture Authority Mesh

Purpose: Make autonomy readable as routed authority instead of broad permission.

Fields:

- Authority lane.
- Allowed public behavior.
- Proof required.
- Stop condition.
- Proof route.

Rules:

- The mesh appears after the run inspector and before memory continuity so visitors see request behavior before continuity claims.
- The SVG remains textless and decorative; native details/summary controls carry every lane, proof rule, and boundary.
- The mesh cannot grant runtime authority, execute work, read private data, write files, deploy, post publicly, spend, connect wallets, sign, or broadcast Web3 transactions.
- Any future automation, wallet, deployment, publishing, or private-tool lane must name exact approval and proof packet before public motion is implied.

### Architecture Approval Packet

Purpose: Make high-risk action handoff inspectable before an organism can move from proof to motion.

Fields:

- Request record.
- Evidence bundle.
- Risk owner.
- Exact approval question.
- Locked motion path.
- Stop condition.

Rules:

- The packet appears after the Architecture Authority Mesh and before Memory Continuity so visitors see the proof handoff before continuity or self-evolution claims.
- The SVG remains textless and decorative; native details/summary controls carry every approval field, proof route, and boundary.
- The packet must name changed files, destination, public wording, rollback, source evidence, and risk owner before deployment, publishing, spending, private data access, wallet motion, generated code integration, or outreach is implied.
- The packet cannot approve itself, mutate files, deploy, publish, spend, pull private data, connect wallets, sign, broadcast Web3 transactions, change status, or contact anyone.

### Memory Recall Receipt

Purpose: Make memory-bearing answers inspectable before recall becomes influence.

Fields:

- Source trace.
- Freshness gate.
- Use boundary.
- Proof return.
- Stop condition.

Rules:

- The receipt appears after Memory Continuity and before the six-layer overview so visitors can separate where memory lives from how recall is allowed to shape a response.
- The SVG remains textless and decorative; native details/summary controls carry every recall field, proof route, and boundary.
- Recall must name source type, freshness, allowed use, and proof return before it supports an answer, recommendation, route, draft, refusal, or unknown.
- The receipt cannot store hidden memory, infer identity, personalize, pull private data, execute, deploy, post, spend, change status, connect wallets, sign, or broadcast Web3 transactions.

### Website Awareness Console

Purpose: Answer "is the Brain aware of its own website?" with a governed architecture surface instead of an overclaim.

Fields:

- Public site map.
- Awareness receipt.
- Approved memory lane.
- Blocked private claims.
- Proof route.
- Authority stop.

Rules:

- The console appears after the Memory Recall Receipt and before the six-layer overview so visitors move from bounded recall into the public website-awareness contract.
- The SVG remains textless and decorative; native radio controls carry every awareness lane, proof route, and boundary.
- Awareness answers may use public routes, metadata, status receipts, approved memory, and proof links, but must name stale or missing verification instead of inventing current live state.
- The console cannot chat with the Brain, scrape private data, infer visitor identity, read analytics, mutate files, deploy, post publicly, spend, connect wallets, sign transactions, change status, or broadcast Web3.

### Experience Principles Ledger

Purpose: Make the full UX audit usable as a public build map, not just internal research prose.

Fields:

- Research lens.
- Why it works.
- Unwind reinterpretation.
- Implementation opportunity.
- Proof route.

Rules:

- Every requested research lens must map to a visible proof route before it becomes a production recommendation.
- Implementation opportunities must preserve the organism identity and must not clone source design language, section rhythm, release taxonomy, illustration treatment, or brand system.
- Emotional progression remains reversible and consent-bound; attention management remains public navigation, not profiling, telemetry, or hidden personalization.

### Runtime Budget Ledger

Purpose: Make performance strategy inspectable before any richer runtime layer is approved.

Fields:

- Runtime lane.
- Budget or cost ceiling.
- Allowed behavior.
- Proof route.
- Stop condition.

Rules:

- Semantic HTML remains the source of meaning before SVG, canvas, WebGL, or animation.
- Bilingual proof copy must stay route-sharded: edit `i18n/source.js`, regenerate with `npm run i18n:split`, keep shared i18n limited to navigation/footer/chat labels, and verify route coverage before adding new language-heavy surfaces.
- No dependency is added for a single visual enhancement while the current Vite surface can explain the system with HTML, CSS, and SVG.
- Three.js, GSAP, Framer, WebGL, live polling, and richer media stay behind route-specific proof, mobile behavior, cleanup, fallback, and explicit approval gates.
- The generated Runtime Budget Evidence artifact at `/assets/specs/unwindcode-runtime-budget-evidence.json` must be refreshed with `npm run build && npm run budget:evidence` whenever build output changes; `npm run build && npm run budget:check` is the release gate before deployment.

### Access Mobile Ledger

Purpose: Make accessibility and mobile strategy inspectable before the organism adds richer motion, depth, or compact navigation behavior.

Fields:

- Access lane.
- Rule.
- Compact behavior.
- Proof route.
- Stop condition.

Rules:

- Route recovery, keyboard operation, visible focus, language parity, reduced-motion meaning, and text-first proof must be visible before optional visual depth expands.
- Mobile navigation must recover the user to home, proof, organisms, transmissions, Talk to Brain, and Build With Us without label collision or horizontal overflow.
- Forms, chat prompts, and compact inputs cannot trigger hidden data pulls, silent execution, deployment, posting, spending, outreach, or Web3 broadcast.

### System Reflection Ledger

Purpose: Make the backend-to-frontend reflection rule visible before the interface adds richer visual intelligence.

Fields:

- Public surface.
- Real organism layer represented.
- State label.
- Proof route.
- Stop condition.

Rules:

- Every visual, animation, console, map, status indicator, card, and intake prompt must name the real workflow, memory layer, organism capability, proof source, or approval boundary it represents.
- Prototype, research, experimental, live, local-proof, and manual-posting states must remain separate at the surface where visitors encounter the claim.
- No public surface may imply live telemetry, hidden memory, identity inference, autonomous execution, deployment, public posting, spending, outreach, private data pull, or Web3 broadcast unless the verified backend source and authority boundary are visible.

### Rollout Readiness Ledger

Purpose: Make the production rollout plan inspectable before local proof becomes public motion.

Fields:

- Rollout phase.
- Exit evidence.
- Release gate.
- Rollback route.
- Authority boundary.

Rules:

- Local proof, public metadata, tests, build output, and browser verification must be aligned before deploy approval is requested.
- The user must explicitly ask to deploy the current version before any production push, alias promotion, transmission publication, or social packet release.
- Rollout phases cannot promote research, prototype, local-proof, stale, or manual states into live claims unless the verified source and authority boundary are visible.

### Production Checkpoint Ledger

Purpose: Make approved production deployments inspectable after they happen, without turning the site into an automatic deployment controller.

Fields:

- Checkpoint lane.
- Evidence.
- Artifact.
- State.
- Authority boundary.

Rules:

- A deployment checkpoint must name the local verification, production build, runtime budget status, public alias, live surface checks, and approval scope that allowed the alias to move.
- A checkpoint is a record of one approved deploy, not standing permission for future deploys, public posts, spend, outreach, private data pulls, filesystem writes, rollback, monitoring, or Web3 broadcast.
- The checkpoint artifact must remain machine-readable and mirrored in `llms.txt`, `ai-services.json`, `assets/asset-manifest.json`, `sitemap.xml`, the implementation packet, and tests.

### Live Parity Gate

Purpose: Keep local proof, public alias checks, explicit deploy approval, and completion claims separated whenever the site evolves faster than production.

Fields:

- Parity lane.
- Evidence.
- Artifact.
- State.
- Authority boundary.

Rules:

- The gate must name which evidence is local and which evidence requires a live cache-busted public check after deploy.
- User approval to deploy the exact current version is part of the architecture and must stay visible near production proof.
- A local pass cannot be described as live parity until the public alias serves the same proof surface, discovery files, and API boundaries.
- The gate cannot deploy, promote aliases, roll back, monitor users, approve completion, post publicly, spend, pull private data, write files, change status, or broadcast Web3 transactions.

### Experience Evolution Acceptance Ledger

Purpose: Keep the full evolution goal visible as evidence so future agents cannot shrink completion to whichever surface was just edited.

Fields:

- Acceptance lane.
- Requirement.
- Evidence route.
- State label.
- Stop condition.

Rules:

- The ledger must map source freshness, identity preservation, backend reflection, experience research, implementation architecture, and rollout authority to inspectable proof.
- It records evidence for the current goal, not automatic goal completion.
- It cannot approve dependencies, framework migration, deployment, public posting, spend, outreach, private data pulls, filesystem writes, rollback, monitoring, or Web3 broadcast.
- Any unmet or future capability stays labeled as local proof, research, prototype, experimental, or live according to its real state.

### Completion Audit Ledger

Purpose: Make completion claims inspectable before anyone treats the active frontend evolution goal as finished.

Fields:

- Audit lane.
- Evidence route.
- State.
- Audit condition.
- Blocked authority.

Rules:

- The ledger must separate proven current surfaces, governed immersive asset pipeline, blueprint-only architecture, live release proof, and completion claim authority.
- The machine-readable completion audit must record completion_not_claimed until current tests, build, runtime budget, public alias, discovery files, route parity, and authority boundaries agree at claim time.
- Premium hero visuals, organism identity graphics, architecture diagrams, Web3 trust visuals, social previews, parallax layers, canvas effects, particle systems, shader-inspired visuals, WebGL scenes, and Three.js opportunities need purpose, text policy, motion policy, mobile behavior, dependencies, target weight, and proof route before they can support a public claim.
- Route-specific social previews should replace the default lab card only when the route has enough durable semantics to justify a distinct visual. The Architecture preview qualifies because it maps gateway intake, cortex routing, memory receipt, cell work, immune lock, proof return, and approval boundary without implying hidden execution, filesystem authority, dependency installation, self-approval, deployment, public posting, spending, private data access, wallet control, or Web3 broadcast authority. The Proof preview qualifies because it maps source router, artifact ledger, status mirror, awareness gate, runtime budget, live parity, proof return, and authority gate without implying hidden telemetry, private self-awareness, status mutation, deployment power, public posting authority, spending authority, private data access, wallet control, or Web3 broadcast authority. The Build With Us preview qualifies because it maps role signal, conversion packet, signal composer, protocol readiness, intake receipt, sprint scope, proof return, and approval lock without implying hidden lead scoring, hidden outreach, automatic work start, file writes, deployment power, public posting authority, spending authority, private data access, wallet control, transaction signing, or Web3 broadcast authority. The Transmissions preview qualifies because it maps public memory, release ledger, carousel packet, proof route, approval gate, public archive, subscriber signal, and authority lock without implying automatic publishing, hidden outreach, private reasoning disclosure, unreviewed claims, deployment power, file writes, spending authority, wallet control, transaction signing, or Web3 broadcast authority. The Organisms preview qualifies because it maps the flagship organism paths and shared proof boundary. The Infinity Mirror preview qualifies because it maps state signal, reflection loop, memory consent, artifact return, choice path, and human boundary without implying diagnosis, identity inference, hidden memory, care decisions, forced camera, public action, private data access, spend, deployment, or Web3 broadcast authority. The Financial Organisms preview qualifies because it maps chain read, off-chain simulation, unsigned review packet, custody boundary, broadcast lock, and proof return without implying wallet connection, transaction signing, spending, live advice, or Web3 broadcast authority. The Brain Cell Architecture preview qualifies because it maps problem signal, research packet, sandbox proof, integration gate, approval lock, and proof memory without implying hidden execution, filesystem authority, self-approval, deployment, public posting, spending, private data access, or Web3 broadcast authority. The Visual Cortex preview qualifies because it maps creator signal, brand memory, storyboard proof, render QA, release packet, and approval lock without implying publishing, upload/account access, likeness use, spend, targeting, deployment, public posting, private data access, or Web3 broadcast authority. In all cases, HTML metadata, schema, llms.txt, ai-services.json, and the asset manifest carry the inspectable claim.
- The ledger cannot mark the goal complete, generate assets, approve dependencies, migrate frameworks, approve WebGL, deploy, post publicly, spend, pull private data, write files, change status, or broadcast Web3 transactions.

### Requirement Coverage Ledger

Purpose: Expand the full Experience Evolution objective into granular coverage lanes so future agents can inspect each named deliverable family instead of treating the latest edited surface as completion.

Fields:

- Coverage lane.
- Requirement family covered.
- Evidence route.
- State.
- Stop condition.

Rules:

- The ledger must name source research, UX audit, design research, information architecture, component recommendations, motion architecture, digital biology, React/Next architecture, Framer specs, Three.js gates, design tokens, asset requirements, accessibility, mobile, SEO, performance budgets, rollout, and production proof.
- Every lane must point to a durable public proof route or public artifact.
- The ledger records coverage evidence only; it cannot declare completion while any public parity, future migration, dependency, runtime depth, or authority boundary remains unverified.
- It cannot approve migration, install dependencies, deploy, monitor users, post publicly, spend, pull private data, change status, or broadcast Web3 transactions.

### Objective Deliverable Index

Purpose: Expose each exact named output from the active objective as a separate proof obligation so broad coverage lanes cannot hide missing deliverables.

Fields:

- Deliverable name from the objective.
- Evidence route the visitor can inspect.
- Current state label.
- Stop condition that prevents the deliverable from becoming an unreviewed claim.

Required deliverables:

- UX Audit.
- Design Research.
- Information Architecture Improvements.
- Component Recommendations.
- Motion Architecture.
- Accessibility Improvements.
- Mobile Strategy.
- SEO Preservation.
- Production Rollout Plan.
- React Architecture.
- Next.js Structure.
- Framer Motion Specs.
- Three.js Opportunities.
- Design Tokens.
- Asset Requirements.
- Performance Budgets.

Rules:

- The index is evidence routing, not a completion certificate.
- It must stay synchronized with the implementation packet, proof page, `llms.txt`, `ai-services.json`, asset manifest, and tests.
- It cannot approve dependencies, migrate frameworks, deploy, post publicly, spend, pull private data, infer identity, change status, or broadcast Web3 transactions.

### Production Recommendation Gate

Purpose: Convert the objective's "only recommend production-ready solutions" rule into a visible gate before future implementation work starts.

Fields:

- Recommendation lane.
- Proof required.
- Evidence route.
- State label.
- Blocked authority.

Rules:

- The gate sits after the Objective Deliverable Index and before discovery preservation so visitors see each named deliverable before the production-ready criteria.
- Current static Vite pages, React/Next migration, Framer or GSAP motion leaves, Three.js depth, tokens/assets, and release authority must each name proof required, evidence route, state, and blocked authority.
- A recommendation cannot be called production-ready when it lacks semantic fallback, reduced-motion behavior, mobile policy, budget evidence, rollback route, and explicit approval for high-risk actions.
- The gate cannot approve dependency installation, framework migration, WebGL runtime, deployment, alias promotion, rollback, public posting, outreach, spending, private data pulls, filesystem writes, status mutation, hidden telemetry, identity inference, or Web3 broadcast.

### Homepage Production Proof Pulse

Purpose: Translate latest-release clarity into Unwind-native proof memory on the homepage.

Fields:

- Proof pulse lane.
- Release evidence.
- Artifact route.
- State label.
- Authority boundary.

Rules:

- The pulse should sit inside the system-state band so release memory appears after live/prototype/research states are named.
- It must expose current test count, production checkpoint artifact, conversion proof, discovery metadata, and the manual authority boundary.
- It cannot become a live monitor, deployment controller, alias promoter, rollback system, telemetry layer, public posting approval, spend approval, private-data approval, or Web3 broadcast authority.

### Research Organisms Hero Console

Purpose: Make the Research Organisms first viewport explain source-bound method before research claims ask for belief.

Fields:

- Source packet.
- Question map.
- Bounded experiment.
- Synthesis route.
- Publication gate.
- Textless decorative SVG.

Rules:

- The console appears before the research brief so first-time visitors understand provenance, uncertainty, experiment, translation, and caveat-preserving publication before deeper ledgers.
- The SVG remains decorative and textless; semantic links, bilingual copy, durable anchors, and route CSS carry all meaning.
- The console cannot fabricate citations, scrape private context, imply affiliation, promote speculation into certainty, publish unattended, deploy, spend, pull private data, create live status, or broadcast Web3.

### Research Loop Surface

Purpose: Make serious research organisms legible without implying live autonomy.

Fields:

- Research question.
- Current artifact.
- Next experiment.
- Blocked claims.
- Approval needed.

### Research Translation Ledger

Purpose: Show how research becomes product-safe language only after source scope, backend reality, experiment evidence, allowed next state, and blocked claims survive review.

Fields:

- Translation lane.
- Research question.
- Evidence route.
- Allowed next state.
- Blocked claim.

Rules:

- Separate external inspiration from Unwind-native implementation.
- Translate only into surfaces that reflect a real workflow, memory layer, proof route, or approval boundary.
- Do not promote research into live product authority without current proof and human review.
- Do not imply affiliation, copied design, hidden telemetry, private memory, unattended publication, deployment, spend, outreach, private data pull, or Web3 broadcast.

### Public Learning Loop

Purpose: Translate release cadence into inspectable memory instead of generic blog promotion.

Fields:

- Release beat or next research memory.
- State: Live or Research.
- Artifact route.
- Proof packet.
- Authority boundary.
- Next route to inspect.

### Transmissions Hero Console

Purpose: Make the archive legible in the first viewport by turning the opening panel into a proof router rather than a list introduction.

Fields:

- Latest build record.
- Whitepaper architecture.
- Safety gate.
- Web3 boundary.
- Social packet desk.
- Collaboration path.
- Authority boundary.

Rules:

- Keep the SVG decorative and textless; all meaning must live in semantic links, bilingual labels, schema, and metadata.
- Preserve visible keyboard focus for every proof route.
- Do not let the console publish, post, deploy, spend, trigger outreach, pull private data, promote status, connect wallets, sign, or broadcast Web3.

### Transmission Release Memory Ledger

Purpose: Make the latest transmission releases inspectable as public organism memory before a reader drops into the archive.

Fields:

- Date.
- Transmission number and title.
- State label.
- What changed.
- Proof artifact.
- Authority boundary.
- Next inspection route.

Rules:

- Place the ledger before reader lanes so release memory is visible early.
- Keep every row semantic and readable without JavaScript.
- Do not let the ledger publish, post, deploy, spend, trigger outreach, pull private data, promote status, or broadcast Web3.

### Authority Gradient

Purpose: Keep action boundaries visible across the site.

Rungs:

- Observe.
- Reflect.
- Draft.
- Sandbox.
- Approval.
- Public motion.

Fields:

- State label: Live, Prototype, Experimental, or Research-gated.
- Allowed behavior.
- Proof artifact.
- Stop condition.
- Route to inspect.

## Motion Architecture

Motion contract for every animated layer:

```text
Name:
Trigger:
Meaning:
System represented:
Duration:
Easing:
Reduced-motion behavior:
Mobile behavior:
Fallback:
Cleanup:
Stop condition:
Proof source:
Authority boundary:
```

Motion rules:

- Animation must express signal, memory, routing, proof, learning, or boundary.
- Do not animate a capability that is only a future claim unless it is labeled Concept or Research.
- Do not make motion the only place where meaning exists.
- Stop animation on reduced motion, compact screens when necessary, and background tabs.
- Do not introduce Three.js until a route has a real depth reason, a static fallback, and a verified mobile shutdown path.

## Accessibility Improvements

- All critical content must be semantic HTML or i18n-backed text.
- Navigation must remain keyboard operable with visible focus, Escape close, and stable tab order.
- Hash targets need scroll margins under the fixed glass nav.
- Interactive maps use native controls before custom gesture surfaces.
- Visual assets should be textless unless the artifact is explicitly social-media raster output.
- Reduced-motion mode preserves story order and proof access.

## Mobile Strategy

Mobile is not a compressed desktop poster. It is the clearest proof path.

- Navigation opens from right to left as a readable glass drawer.
- Long words and route names must never collide with the brand.
- Talk to Brain and Build With Us remain reachable inside the drawer.
- Hero content should prioritize thesis, boundary, and first action before decorative depth.
- Complex diagrams collapse into semantic cards with proof links.
- Canvas and WebGL shut down or become static when they threaten reading, battery, or layout stability.

## SEO Preservation

Existing public discovery surfaces must remain aligned:

- Canonical routes.
- Open Graph and Twitter metadata.
- JSON-LD schema.
- `llms.txt`.
- `ai-services.json`.
- `assets/asset-manifest.json`.
- `sitemap.xml`.
- Transmission pages and archive.
- Public spec files under `/assets/specs/`.

New features should not be considered done until the public discovery layer names the feature, its proof source, and its authority boundary.

The implementation packet at `/assets/specs/unwindcode-experience-evolution-implementation-packet.json` must stay synchronized with this audit whenever public IA, component contracts, motion policy, future migration rules, or proof boundaries change.

## React Architecture

If the site migrates from the current static Vite implementation to React/Next, use this component split:

```text
app/
  page.tsx
  organisms/
    page.tsx
    infinity-mirror/
      page.tsx
      experience/page.tsx
    visual-cortex/page.tsx
    financial-organisms/page.tsx
    brain-cell-architecture/page.tsx
  architecture/page.tsx
  proof/page.tsx
  transmissions/page.tsx
  philosophy/page.tsx
  build-with-us/page.tsx

components/
  navigation/GlassLabNav.tsx
  organism/OrganismStatusRail.tsx
  organism/CapabilityLedger.tsx
  proof/AuthorityGradient.tsx
  proof/ProofRouteCard.tsx
  motion/MotionContractLedger.tsx
  gateway/ConversationGateway.tsx
```

Server-render by default. Client leaves are allowed only for local state selectors, progressive animation, or bounded demos with no hidden storage, network call, file write, spending, deployment, public posting, Web3 broadcast, identity inference, or autonomy authority.

## Next.js Structure

Recommended constraints for a future Next.js migration:

- App Router.
- Static generation for public pages.
- Route metadata generated from one content model.
- Public specs copied into `/public/assets/specs/`.
- `llms.txt`, `ai-services.json`, sitemap, and schema generated from the same source data.
- Client components isolated to interaction leaves.
- No motion library in the root shell.

## Framer Motion Specs

Approved Framer uses:

- Button/toggle state transitions.
- Proof card entry once visible.
- Status rail state changes.
- Infinity Mirror chapter microinteractions.
- Drawer open/close after CSS fallback exists.

Blocked Framer uses:

- Hiding critical text until animation completes.
- Infinite background motion without meaning.
- Route transitions that break direct hash links.
- Mobile parallax that reduces readability.

## Three.js Opportunities

Use Three.js only when a 3D scene gives the visitor inspectable understanding:

- Infinity Mirror depth gate: a reflective proof tunnel where each depth layer corresponds to signal, memory, cells, authority, and proof.
- Brain Cell Architecture: a cell network that reveals sandbox, test, and integration gates.
- Financial Organisms: a no-broadcast trust simulation where signed motion is visibly locked and source, risk, authority, and proof-return readiness gates are inspectable before value motion is considered.

Three.js requirements:

- Static SVG or semantic fallback first.
- No mobile WebGL by default.
- Reduced-motion and low-power shutdown.
- Pixel verification for nonblank canvas.
- No critical text inside the canvas.

## Design Tokens

Recommended token families:

```text
color.bg.void
color.bg.glass
color.text.primary
color.text.muted
color.signal.violet
color.signal.cyan
color.signal.gold
color.signal.green
color.boundary.red
color.proof.blue

radius.card
radius.instrument
radius.portal

shadow.glass
shadow.proof
shadow.boundary

space.section
space.panel
space.control

motion.duration.fast
motion.duration.medium
motion.duration.slow
motion.easing.signal
motion.easing.boundary
```

Palette rule: avoid a one-note purple or dark-blue interface. Violet can be the signal color, but proof, boundary, memory, Web3, and human authority need distinct secondary colors.

The public Digital Biology Token Ledger on `/proof/#token-ledger-title` is the governed reader-facing version of these families. Future implementation should treat the packet tokens as source data and the proof-page ledger as the authority boundary for how those tokens may appear in interface surfaces.

## Asset Requirements

Every new asset must include:

- Asset id.
- Route and surface.
- Purpose.
- Trust value.
- Accessibility behavior.
- Text policy.
- Motion policy.
- Performance budget.
- Owner.
- Last reviewed date.

Assets should not be approved if they only make the page look futuristic. They must clarify architecture, trust, product path, or proof.

## Performance Budgets

Targets for current static/Vite implementation:

- No new runtime dependency for a single visual enhancement.
- SVG visual assets should target under 20 KB when possible.
- Canvas should stay bounded and decorative.
- Social PNG packets load previews lazily and expose downloads by explicit action.
- WebGL is excluded from production routes until a specific approval gate.
- Build should pass with existing large chunk warning only.

Targets for future React/Next implementation:

- Root shell remains server-rendered.
- Motion libraries are route-level or component-level, never global by default.
- First viewport does not wait on WebGL, video, or noncritical animation.
- Mobile gets semantic content first and optional depth last.

## Production Rollout Plan

### Phase 1: Clarity And Navigation

- Finish glass nav, governed Brain gateway action, and right-side mobile drawer.
- Add state labels to organism entry surfaces.
- Tighten first-viewport thesis and route hierarchy.

### Phase 2: Proof Proximity

- Move proof links closer to organism claims.
- Add capability ledger cards to each organism page.
- Add a homepage System State Console that maps current routes, gateway, transmissions, Web3 simulation, and intake to state labels, proof, boundaries, and a same-origin `/api/status` receipt with a static fallback.
- Align `llms.txt`, `ai-services.json`, and asset manifest after each public surface.

### Phase 3: Runtime Reflection

- Map visible dashboards and maps to real workflows.
- Label non-live states directly.
- Add motion contracts before expanding animation.

### Phase 4: React/Next Migration Option

- Migrate only after static surfaces and metadata are stable.
- Keep server-rendered content first.
- Isolate Framer, GSAP, and Three.js to approved leaves.

### Phase 5: Living Proof Layer

- Connect live status only when a real backend source exists.
- Keep stale, manual, research, and prototype labels honest.
- Turn approved transmissions into page, metadata, proof packet, and Instagram carousel.

### Packet Gate

- Any future React, Next.js, Framer, GSAP, Three.js, WebGL, or new runtime dependency proposal must map back to the implementation packet before work starts.
- If the packet and page disagree, treat the page as unverified until the audit, packet, metadata, and tests are synchronized.
- Deployment, posting, Web3 broadcast, outreach, spending, and filesystem changes remain human-approved actions even when a packet says a surface is ready to build.

## Acceptance Criteria

- Visitors can explain what an AI organism is after the first two sections.
- Builders can find architecture and implementation proof.
- Investors can find status, evidence, and authority boundaries.
- Users can understand Infinity Mirror without thinking it diagnoses or decides for them.
- Protocols can see that Financial Organisms are simulation-first, no-broadcast by default, and blocked from value motion until source freshness, risk budget, authority owner, and proof return are inspectable.
- Collaborators can send a bounded first packet.
- Every visual asset has a job, a proof source, and a boundary.
- Non-live capability states are labeled.
- Public metadata, discovery files, tests, and build remain aligned.