# Arken — Full Locked Copy and Brand Brief

This is the canonical plain-text export of the Arken site's locked copy,
voice, archetypes, section grammar, architecture brief, and homepage
priorities. Generated from the project repository.

Site: https://thearken.com
Generated: 2026-05-27T15:52:16Z

---


============================================================
# Source: docs/brand/EXECUTION-BRIEF.md
============================================================

# Arken Website — Locked Execution Brief

**Status:** LOCKED. Do not reinterpret into a conventional AI SaaS homepage.
The strategic differentiation depends on restraint, governance, editorial
pacing, and evidence-based visual language.

## Arken IS NOT
- a generic AI startup
- a productivity SaaS tool
- an AI copilot
- an automation platform
- a dashboard company

## Arken IS
- a governed intelligence system for regulated work
- a premium operational platform
- a traceable decision environment
- a source-backed work system

## Visual & emotional target
A controlled evidence brief brought to life as a platform.

The website must feel: calm · editorial · premium · operationally serious ·
highly intentional · trustworthy under scrutiny.

## Banned visual patterns
AI gradients · neon colors · generic glassmorphism · dark cyberpunk aesthetics ·
dashboard overload · dense feature grids · startup-style motion · floating
particles · playful SaaS interactions · excessive cards · generic icon
libraries · fake AI illustrations.

## Visual register (use)
- Large editorial serif typography (Georgia for home headings)
- Restrained cool slate + champagne palette
- Strong whitespace
- Asymmetrical premium layouts
- Evidence-style visual systems
- Trace-line geometry
- Source-node visual language
- Governed interaction states
- Minimal but meaningful motion

## Banned language
AI platform · AI-powered · agents · automation · productivity · unlock
insights · transform your business · smart assistant · copilot.

## Arken-native language
Approved knowledge · defensible decisions · traceable evidence · governed work ·
validated action · source-backed outputs · declared gaps · expert corrections ·
institutional memory · authorization before reasoning · audit-ready work.

## Locked homepage spine
1. Top banner — Authorization on reasoning
2. Hero — governed decision artifact (gold → blue flip on Accept)
3. Stakes — scrutiny before speed
4. Mechanism — Trace · Validate · Gap · Knowledge
5. Work Arken strengthens
6. Built for regulated teams
7. Architecture & trust
8. Pilot CTA

## Locked navigation
Work · Industries · Architecture · Resources · About · **Book a pilot briefing**
(single primary CTA, no secondary). See `homepage-priorities-v1.3.md` §8 for
sub-items.

## Hero artifact rules
- Lead with the proposed decision, not metadata
- 2–3 cited sources with source-node markers
- Trace ID in locked format: `TRACE · YYYY-MM-DD · 4-character ID`
- Confidence · Pack rules in scope: 12 · Role
- Action row: Accept / Escalate / Declare gap
- **Gold = AI proposal awaiting validation**
- **Blue = human-accepted decision** (signature motion: 700ms flip on Accept)

## Motion rules (functional, not decorative)
Source path resolves into proposal · gold border flips to blue after
validation · broken trace line appears when evidence is missing · gap
declaration pauses the flow · expert correction becomes institutional knowledge.

Avoid: floating particles · bouncy SaaS animations · decorative glows ·
parallax overload · confetti.

## Layout constraints
- Max content width ~1180px
- Large whitespace bands between sections
- No section visually competes with hero
- Avoid equal-weight card grids
- Buttons secondary to typography
- Borders subtle, shadows architectural not playful

## Source files
- `homepage-priorities-v1.3.md` — full priorities doc
- `homepage-mockup-v1.3.html` — visual baseline
- Implementation: `src/v3/shared/blocks/home29/`


============================================================
# Source: docs/brand/homepage-priorities-v1.3.md
============================================================

# Arken Homepage Premium Design Priorities

**Purpose:** Consolidated homepage design direction for updating Arken into a premium, differentiated brand — not another generic AI startup.

**Core brand direction:** Arken should feel like a governed intelligence system for regulated work. The homepage should behave like a controlled evidence brief: calm, precise, traceable, defensible, and operationally serious.

---

## Priority 1 — Reset the Homepage Structure

The homepage should have one clear spine, not a stack of feature blocks.

### Recommended flow

1. **Hero** — one claim, one governed decision artifact, one CTA.
2. **Stakes** — audit, deadline, confident-but-wrong AI.
3. **Trace · Validate · Gap · Knowledge** — Arken’s core operating model.
4. **Work Arken strengthens** — routes by buyer problem.
5. **Built for regulated teams** — routes by industry.
6. **Architecture & trust** — route for technical, security, compliance, and enterprise buyers.
7. **Pilot CTA** — focused enterprise conversion.

### Remove or move deeper

- Large comparison tables
- Long FAQ walls
- Repeated feature cards
- Generic trust sections
- Generic “AI platform” explanations
- Repeated CTA bands

### Rule

The homepage should answer:

- What is Arken?
- Why does it matter?
- Why is it different?
- Where do I go next?
- How do I start?

---

## Priority 2 — Make the Hero Artifact More Ownable

The hero artifact should become Arken’s signature object.

### Shift from

A polished SaaS product card.

### Shift to

A governed decision artifact: an evidence-backed decision brief.

### Artifact requirements

- Lead with the proposed decision, not metadata.
- Show 2–3 cited sources as evidence.
- Include Trace ID.
- Include confidence, role, and rules in scope.
- Keep the action row visible: **Accept / Escalate / Declare gap**.
- Use **gold → blue authorship state**:
  - Gold = AI proposed / awaiting validation.
  - Blue = human accepted or edited.

### Avoid

- Analytics dashboard feel
- Generic chat UI
- CRM-style cards
- Excessive metadata rows
- Overly boxed layouts

---

## Priority 3 — Create the Arken Signature Visual System

The site needs an ownable visual grammar, not generic line icons.

### Core visual language

**Source → Chain → Decision → Validation → Gap → Knowledge**

### Signature components

1. **Trace line** — connects evidence, rules, decisions, and validation.
2. **Source node** — small geometric marker based on Arken logo geometry.
3. **Decision artifact** — governed brief, not dashboard card.
4. **Gold → blue validation flip** — Arken’s signature motion/state change.
5. **Gap mark** — broken trace line/open node, not a generic warning triangle.
6. **Knowledge mark** — correction becomes institutional memory.
7. **Custom icon family** — built from Arken angles, thin slate strokes, one champagne accent.

### Rule

Arken should not have generic illustrations. Arken should have evidence diagrams.

---

## Priority 4 — Reduce Card Density

The current design should feel less like a stack of UI components and more like a premium editorial flow.

### Update rules

- Use cards only for product proof.
- Replace repeated card grids with type, spacing, trace lines, and soft section bands.
- Make the Stakes section a flowing editorial strip, not three equal cards.
- Make work routes lightweight clickable rows or tiles.
- Make industries a compact “built for” band, not another heavy grid.
- Move full comparison tables to deeper pages.

### Question for every section

Does this need a card, or can hierarchy be created with type, whitespace, and a trace line?

---

## Priority 5 — Make Motion Part of Governance

Motion should not be decorative. It should show controlled state change.

### Motion patterns

- Source path resolves into proposal.
- Gold border flips to blue after validation.
- Broken trace line appears when evidence is missing.
- Gap declaration pauses the flow.
- Expert correction becomes institutional knowledge.
- Architecture diagram narrows evidence before reasoning.

### Avoid

- Floating AI particles
- Bouncy SaaS animations
- Decorative glows
- Parallax overload
- Confetti/success animations

### Motion story

Evidence moves. Decisions resolve. Gaps stop. Corrections compound.

---

## Priority 6 — Strengthen the Editorial Feel

The site should feel like a premium intelligence brief, not a SaaS template.

### Update rules

- Use larger serif headline moments.
- Use shorter body copy.
- Use more asymmetry.
- Alternate quiet text sections with proof artifacts.
- Replace feature language with thesis language.
- Use fewer words, larger ideas, more whitespace, sharper proof.

### Example language shift

Instead of:

> Powerful AI workflows for regulated teams.

Use:

> Approved knowledge becomes work your team can defend.

---

## Priority 7 — Reduce Generic AI Language

Arken should not sound like the crowded AI market.

### Minimize or remove

- AI platform
- AI-powered
- Agents
- Automation
- Productivity
- Unlock insights
- Transform your business
- Smart assistant
- Copilot

### Use Arken-native language

- Approved knowledge
- Defensible decisions
- Traceable evidence
- Governed work
- Validated action
- Source-backed outputs
- Declared gaps
- Expert corrections
- Institutional memory
- Authorization before reasoning
- Audit-ready work

### Rule

The site should not sound like it is selling AI. It should sound like it is selling confidence under scrutiny.

---

## Priority 8 — Refine the Navigation Architecture

The navigation should route buyers by need, not by SaaS taxonomy.

### Recommended nav

- **Work**
  - Audit response
  - Bid & tender
  - Safety case
  - Contract review
  - Regulatory change
  - Record retention

- **Industries**
  - Maritime
  - Defence
  - Aerospace
  - Energy
  - Legal

- **Architecture**
  - Authorization before reasoning
  - Traceability
  - Human validation
  - Deployment & security

- **Resources**
  - Architecture paper
  - Pilot guide
  - Use cases
  - Founder notes

- **About**

- **CTA**
  - Book a pilot briefing

### Avoid nav labels

- Product
- Platform
- Solutions
- AI
- Agents
- Features

---

## Priority 9 — Make the Core Mechanism Brand-Led

The strongest evolved framework is:

# Trace the chain.  
# Validate the decision.  
# Declare the gap.  
# Compound the knowledge.

### Why this is stronger

- **Trace the chain** explains more than citations. It shows how connected evidence, rules, expert input, permissions, and prior decisions formed the answer.
- **Validate the decision** makes human judgment and governance explicit.
- **Declare the gap** shows Arken does not guess when evidence is missing.
- **Compound the knowledge** shows expert correction becomes institutional memory.

### Shorthand brand system

**Trace · Validate · Gap · Knowledge**

### Supporting line

Arken does not only show where an answer came from. It shows how connected evidence, rules, expert input, and prior decisions formed the path to that answer.

---

## Priority 10 — Replace Generic Trust Sections with Arken-Native Proof

Do not use generic SaaS trust patterns until they are truly earned.

### Avoid

- Fake logo walls
- “Trusted by leading teams”
- Generic metrics
- Startup-style testimonial blocks
- Big “security, speed, scale” icon grids
- AI transformation claims
- Repeated CTA banners

### Replace with

1. **Product proof**
   - Decision artifact
   - Sources used
   - Trace ID
   - Rules in scope
   - Role
   - Accept / Escalate / Declare gap

2. **Architecture proof**
   - Authorization before reasoning
   - Evidence scoped by role
   - Output validation
   - Audit record

3. **Pilot proof**
   - Approved source set
   - Governed workflow
   - Gap log
   - Reviewed output
   - Correction-to-knowledge record

4. **Founder credibility**
   - Short, serious founder note.

### Rule

Do not say “trust us.” Show the trace, the gap, and who validated it.

---

## Homepage Lock Summary

### Final page spine

1. Hero: governed decision artifact
2. Stakes: scrutiny before speed
3. Trace · Validate · Gap · Knowledge
4. Work Arken strengthens
5. Built for regulated teams
6. Architecture & trust
7. Pilot CTA

### Final positioning

**Decisions you can defend. Every time.**

### Final emotional target

- Institutional confidence
- Calm authority
- Operational seriousness
- Evidentiary trust
- Premium restraint
- Intelligent clarity

### Final design metaphor

A controlled evidence brief brought to life as a platform.


---

## Launch Polish Addendum — v1.3

The following polish fixes were applied after the 90% review:

1. Hero artifact now uses **Pack rules in scope: 12**.
2. Trace ID format is locked as `TRACE · YYYY-MM-DD · 4-character ID`.
3. Stakes copy has been restored to buyer pain language.
4. Work section no longer exposes page strategy language.
5. Architecture paper top banner restored.
6. Architecture proof replaced abstract percentages with categorical governance states: Approved / Authorized / In scope / Validated.
7. Hero source-node legend added.
8. Footer links restored for trust and legal readiness.

### Locked Trace ID format

`TRACE · 2026-04-30 · 7F3A`

### Buyer-facing Stakes copy

- Everything you produce must be complete, current, and cited.
- The team needs approved knowledge, not another unsupported draft.
- A confident answer is not enough when nobody can defend how it was formed.


============================================================
# Source: .lovable/arken-voice-and-vocabulary.md
============================================================

# Arken Voice & Vocabulary

This document governs all customer-facing copy on the Arken site, in marketing,
on LinkedIn, in pitch decks, and in any artifact a buyer might encounter.

The voice is editorial, manifesto register. Bloomberg or Financial Times long-read,
not B2B SaaS landing page. Restraint is the discipline.

This file is canonical. Pre-lock files (including any older `arken-copy.md`) are
deprecated and should not be referenced.

---

## Core principle

Arken is built for regulated buyers — chief engineers, managing partners,
compliance officers, fleet superintendents, CISOs. These readers evaluate depth
as evidence of seriousness. They read long pages. They are punished by their own
organizations for trusting vendors who overclaim. The voice serves them.

The page exists to make a serious buyer want a private briefing. Not to convert
self-serve trials. Not to optimize for short attention. Not to mirror SaaS conventions.

---

## Forbidden vocabulary

### AI as product noun

Never describe Arken as "AI," "an AI platform," "AI-powered," or any variant
where AI is the category. Arken uses language models as ingredient, not identity.

| Forbidden | Use instead |
|---|---|
| "AI-powered decision intelligence" | "The intelligence layer for regulated work" |
| "Our AI" | "Arken" or "the architecture" |
| "Trustworthy AI" | "Defensible work" |
| "Generic AI" | "General models" or "unbound systems" |
| "AI that won't hallucinate" | "Refuses outside its evidence" |

The only acceptable use of "AI" is in section §What We Are Not under the
"Versus general AI" card, where it names a competitor category.

### Marketing softeners

These words signal SaaS register and must not appear on Arken surfaces:

`empower`, `leverage`, `unlock`, `seamlessly`, `transform`, `revolutionize`,
`cutting-edge`, `next-generation`, `mission-critical`, `enterprise-grade`,
`world-class`, `best-in-class`, `industry-leading`, `state-of-the-art`,
`turn X into Y`, `at scale`, `holistically`, `frictionless`

### Internal vocabulary leaks

These are real engineering and architecture terms inside Arken. They do not
appear on customer surfaces. The Substrate Charter explicitly forbids their use
in UI or marketing.

| Internal term | Customer-facing equivalent |
|---|---|
| Substrate / Substrate Charter | Architecture |
| L1–L9 layers / 8-Layer Knowledge Architecture | The Heart pillars (4) |
| L6 authorization | Reviewer-bound, region-scoped |
| RBAC, region-pinned | "scoped to the reviewer" |
| Agent Mesh, multi-agent reasoning | The Chamber (5 facets) |
| Document agent, compliance agent, etc. | Not surfaced |
| Knowledge Fusion Engine (KFE) | Not surfaced |
| Trace map, first-class output | "Trace" (as artifact noun) |
| Corpora | Knowledge, sources |
| Tenant, multi-tenant | Workspace |
| GOKM (as live acronym) | "Goal-Oriented Knowledge Management" written out, with attribution |
| FP-### references | Not surfaced |
| Compounds, compounding (as verb) | "Strengthens the next answer" |

If a buyer asks for technical depth, that lives on `/architecture` and
`/whitepapers/<slug>` pages, where internal vocabulary is unlocked with
inline definitions on first use. Never on the homepage, never on Industry pages.

### Forbidden constructions

- **Three-beat marketing trinities**: "Every X with its Y. Every Y with its Z."
- **Feature comparison tables**: SaaS vs Arken matrix grids
- **FAQ accordions on the homepage** are tolerated only for buyer-due-diligence
  questions, not as a primary content format
- **Customer logo strips** without three named, cleared logos
- **"Coming soon" stubs** for unfinished features
- **Bullet-pointed benefits lists** ("6 Key Benefits of Arken")
- **"Why Arken, Why Now" timing arguments** (investor-deck construct)
- **Step-numbered "How It Works" diagrams** with 5+ steps shown to customers
- **Quote marks around fictional customer praise**
- **Stock photography** of ships, lawyers, doctors, glass conference rooms,
  laptops on desks, abstract data flows, server rooms, cityscapes
- **Hero illustrations** beyond the one mountain composition already on the
  homepage

---

## Master verbs

These seven verbs are Arken's vocabulary core. They appear repeatedly across
the site as deliberate reinforcement.

| Verb | Used for |
|---|---|
| Hold | Defensibility. "Work that has to hold." "When the answer has to hold up." |
| Stand | Independence. "Stand on your own intelligence." |
| Trust | Confidence in output. "Trust the work." |
| Defend | Audit readiness. "Defend the answer." |
| Keep | Knowledge retention. "Keep what was learned." |
| Refuse | First-class output. "Refusal is an answer." "Built to refuse." |
| Begin | Engagement. "When the answer has to hold up." section + CTA. |

The verbs `empower`, `enable`, `drive`, `deliver`, `unlock`, `accelerate` do
not appear in Arken copy.

---

## Permitted vocabulary (page nouns)

These are the operating nouns of Arken's vocabulary:

**Work**: the reader's actual job. Not Arken's product. "Work the procedure."
"The work that has to hold."

**The team**: the actor inside the customer's organization. "Your team."
"Reviewers in the loop."

**The source**: an approved document or record. "Sources used. Sources excluded."

**The trace**: the audit artifact that ships with every answer.

**The record**: the audit log. "The record is the work."

**The architecture**: Arken's structural design. Singular.

**The chamber**: the operational space where work happens. Used in §The Chamber section.

**The lineage**: the GOKM heritage. Used as the section name.

---

## Modifiers permitted

- `Source-traceable` (and `source-backed`)
- `Reviewer-bound`
- `Refusable` (as adjective for outputs)
- `Defensible` (use sparingly — earned through demonstration, not assertion)
- `Audited by design`
- `Sovereign` (only in deployment context)
- `Approved` (sources, decisions)
- `Admitted` (sources cleared by governance)
- `Excluded` (sources outside the team's scope)
- `Cleared` (by review)

---

## Sentence rules

### Short sentences are the discipline

The strongest sentences on the Arken homepage are 3–7 words.

- "Stand on your own intelligence."
- "That refusal is the product."
- "The record is the work."
- "Built to refuse, not to invent."

Long sentences are permitted when they earn it (the Lineage paragraph), but
the default is short, declarative, declarative.

### No hedging

| Forbidden | Use instead |
|---|---|
| "Arken may help your team..." | "Arken returns source-backed answers." |
| "Designed to support..." | "Built for." |
| "Can potentially..." | "Does." Or omit. |
| "Helps you..." | "Returns." Or "Defends." Or omit. |

### Active voice. Direct subject.

Arken is the subject. Not "the platform," not "the system," not "the solution."

"Arken refuses outside its authorization."
Not "The platform refuses outside its authorization."

### Periods, not semicolons or em-dashes in series

Series of declarative statements use periods, not commas with conjunctions.

"On-premise. Air-gapped. In your private cloud. In your sovereign region."

Not: "On-premise, air-gapped, in your private cloud, and in your sovereign region."

The period rhythm is the editorial signature. Lean into it.

---

## Tone register by page type

| Page archetype | Register |
|---|---|
| Homepage (`/`) | Editorial manifesto. Shortest sentences. Strongest verbs. Most restraint. |
| Industry page (`/industries/<slug>`) | Operator-grounded. Industry vocabulary unlocked. Same restraint. |
| Work page (`/work/<slug>`) | Scene-led. Operator-vocabulary heavy. |
| Architecture (`/architecture`) | Dossier. Long-form prose. Section anchors. Citations. Internal vocab unlocked with inline definitions. |
| Paper (`/whitepapers/<slug>`) | Academic. Authored, dated. Citation-rich. |
| Pilot (`/pilots/<slug>`) | Reserved. After-action report. No marketing flourish. |
| Form (`/request-access`) | Calm, operator-named. Field labels in operator language. |
| Index (`/industries`, `/whitepapers`) | Editorial restraint. Card grid + brief Mark Plate. |

---

## The discipline test

Before any copy ships, five questions:

1. Could any line on this surface appear on a HubSpot landing page?
2. Would a chief engineer at 3 AM and a CEO in a board meeting both nod at every sentence?
3. Is every claim defensible? Or is it aspirational? (If aspirational, remove.)
4. Are all partner references contractually cleared? (Or anonymised?)
5. Does the copy surface internal vocabulary anywhere not unlocked by the archetype?

If any answer fails, do not ship.

---

## What this voice is not

This voice is not for B2B SaaS conversion. It will not optimize for
self-serve trial signups, freemium funnels, or short-attention demand-gen
landing pages. The voice exists because Arken's buyers are not those buyers.

The voice is also not "editorial luxury" or "design-magazine register." It is
editorial restraint applied to a serious commercial purpose. Bloomberg's
columnists are not luxury writers. Neither is Arken.

---

## When in doubt

When in doubt, write less. Cut a sentence. Replace a soft verb with a hard one.
Remove the second adjective. Trust the reader to extrapolate.

The page is selling to readers who already evaluate vendors for a living.
They are looking for signal. The voice delivers signal by refusing to deliver
the noise that makes other vendors' pages feel cheap.

End of document.


============================================================
# Source: .lovable/arken-page-archetypes.md
============================================================

# Arken Page Archetypes

This document defines every type of page Arken publishes. Each archetype
specifies who reads it, what voice register it uses, and which section
grammars compose it.

Companion documents:
- `arken-voice-and-vocabulary.md` — language and word choice
- `arken-homepage-locked-text.md` — the canonical homepage as exemplar
- `arken-section-grammar.md` — section composition patterns

If a proposed page does not match any archetype below, the archetype list
is wrong or the page should not exist.

---

## The eight archetypes

| Archetype | URL pattern | Reader | Arc |
|---|---|---|---|
| A — Flagship | `/` | Every reader. The masthead. | Descent |
| B — Industry | `/industries/<slug>`, `/industries` | Industry-specific buyer | Workflow |
| C — Work | `/work/<slug>`, `/work` | Work-specific operator + buyer | Workflow |
| D — Architecture | `/architecture` | Technical buyer, regulator, skeptic | Dossier |
| E — Paper | `/whitepapers/<slug>`, `/whitepapers` | Technical buyer, academic | Dossier |
| F — Pilot | `/pilots/<slug>`, `/pilots` | Procurement buyer, next-pilot CEO | Reserved |
| G — Form | `/request-access`, `/pilot-briefing` | Decided buyer ready to begin | Single Mark Plate |
| H — Index | `/industries`, `/work`, `/whitepapers`, `/pilots` | Catalogue browser | Card Grid |

No other archetypes exist. If a page does not slot here, do not build it.

---

## A — Flagship

The homepage. Every other page descends from it. The voice masthead.

**Reader:** Every reader. Makes no assumptions about industry or stage.

**Register:** Editorial manifesto. Shortest sentences. Strongest verbs. Most restraint.

**Composition:** See `arken-homepage-locked-text.md` for the locked spine.

**Unique constraints:**

- Only page with both §Lineage and §Heart Chamber Moments. Other pages have at most one.
- Only page with the four-line Trust Strip declaration block.
- Only page where Hero is type-only with descent arrow. All other pages open with a Mark Plate that has a CTA or a single inline next-step link.

---

## B — Industry

A page that names one industry and shows how Arken's operating model holds
in that industry's vocabulary, work types, and review patterns.

**Reader:** A buyer or operator from that specific industry who arrived from
the homepage §Industries card, search, or a direct partner link.

**Register:** Operator-grounded. More concrete than Flagship. Industry-specific
vocabulary is unlocked.

**Vocabulary unlock by industry:**

| Industry | Words now permitted |
|---|---|
| Maritime | Vessel, gearbox, chief engineer, fleet, offshore, service history, ABS, IACS, port state, deck |
| Defence & aerospace | Procurement, programme, clearance, past performance, controlled, ITAR-adjacent, Crown procurement, prime |
| Legal | Matter, partner, associate, opinion, memo, brief, archived file, undigitised, motion, deposition, precedent |
| Healthcare operations | Clinical pathway, protocol, unit, ward, quality reporting, M&M, credentialing, standing orders |
| Energy & industrial maintenance | Turnaround, asset, plant, downtime, risk evidence, multi-site, refinery, generation |
| Enterprise governance | The organisation, the operation, accumulated intelligence, defensibility, multi-region |

**Composition (canonical):**

1. **Mark Plate** (Hero) — industry-specific H1 echoing *"Where the answer must hold."* but more concrete (e.g., Maritime: *"The work that has to hold across a fleet."*)
2. **Scene Set** — three industry-specific pain scenes following §3 Stakes grammar
3. **Facet List** (Capability variant, 3–5 facets) — how Arken handles this industry's work, in this industry's language
4. **Two-Column Artifact** — a real artifact from this industry's work (refusal, gap, decision artifact)
5. **Card Grid** (3–4 cards) — work types within this industry that Arken supports
6. **Mark Plate** (Begin) — closing CTA, *"Request a private briefing on <industry> work →"*

**Length:** One screen Hero + 3–5 screens of body. No Lineage or Heart Chamber
Moments — those live on Flagship and `/architecture`.

**Constraints:**

- Industry vocabulary unlocked, but voice rules still apply.
- One industry-named pilot reference allowed only if contractually cleared. Otherwise anonymised.
- No cross-industry comparisons. Each Industry page is self-contained.
- No "trusted by leading <industry> companies" without three named, cleared logos.

---

## C — Work

A page that names one work type and shows how Arken transforms the work.
Examples: Audit response, Bid & tender, Safety case, Contract review,
Regulatory change.

**Reader:** Operator who does this work, OR buyer who owns its outcomes. Both
arrive expecting their week reflected back at them.

**Register:** Scene-led, operator-grounded. Sentences shorter and more specific
than even Industry pages.

**Composition (canonical):**

1. **Mark Plate** (Hero) — work-named H1 (e.g., *"Audit response, source-backed."*)
2. **Scene Set** — one or two extended scenes from this work, longer than §3 Stakes scenes (5–8 sentences each)
3. **Facet List** (Capability variant, 3 facets) — how Arken handles this work
4. **Two-Column Artifact** — an artifact specific to this work
5. **Card Grid** (small, 2–3 cards) — related industries that face this work
6. **Mark Plate** (Begin) — *"Bring one <work> workflow →"*

**Constraints:**

- Scenes in Scene Set must be from different industries — most work types cross multiple verticals.
- No time-saved, hours-reduced, or efficiency-gained statistics. Quantitative claims live on `/pilots` pages after measurement.
- No pricing on Work pages.

---

## D — Architecture

The single deep technical page. Destination for "Read the paper," "Explore
the architecture," and "Read the architecture" links across the site.

**Reader:** Technical buyer or skeptic — CISO, regulator, academic peer. Will
not be persuaded by marketing voice.

**Register:** Dossier. Long-form prose. Section anchors. Citations. Closer to
Bloomberg long-read or FT explainer than to a marketing site.

**Internal vocabulary unlock:** *Substrate, trace map, first-class output,
deterministic conflict resolution* may finally appear here, each properly
defined inline on first use.

**Composition (linear dossier with deep-link anchors):**

1. **Chamber Moment** (opening) — page's thesis statement, with author/date attribution
2. **Anchor: `#thesis`** — the central architectural claim, one paragraph
3. **Anchor: `#authorisation`** — how authorisation runs before reasoning
4. **Anchor: `#trace`** — how the trace is constructed and what it carries
5. **Anchor: `#refusal`** — what a refusal looks like and why it is first-class
6. **Anchor: `#gaps`** — how gaps differ from refusals
7. **Anchor: `#audit`** — audit-by-design, the record-as-work claim
8. **Anchor: `#sovereignty`** — deployment topologies (on-premise, air-gapped, private cloud, sovereign region) and what each guarantees
9. **Anchor: `#lineage`** *(only if `/whitepapers/lineage` doesn't own this anchor)* — GOKM origin and refinement
10. **References block** — academic citations, dated, with links where available
11. **Mark Plate** (Begin) — closing CTA: *"Request a private architecture briefing →"*

**Constraints:**

- Every claim that can be sourced must be sourced. Footnoted citations `[1]`, `[2]` listed at bottom.
- Internal vocabulary is unlocked but every internal term is defined inline on first use.
- Reading experience is **continuous text**, not card-driven. Cards on this page would break the dossier register.
- Diagrams are allowed but never decorative. Each diagram caption explains exactly what it shows and what it does not show.

---

## E — Paper

A single published paper, briefing, or set of field notes, hosted as a page.
The `/whitepapers` index lists them.

**Reader:** Same skeptical reader as Architecture, but on a narrower subject.
Has already committed to reading deeply.

**Register:** Dossier. The most academic register on the site. Authored, dated,
citation-rich.

**Composition:**

1. **Chamber Moment** — paper title, author, date, abstract (50–80 words)
2. **Linear prose sections**, each with its own anchor for cross-page deep linking
3. **References block**
4. **Download link** to a PDF version at the foot of the page, mono uppercase
5. **Mark Plate** (Begin) — closing CTA back to a briefing or further paper

**Constraints:**

- Paper's content is editorial; the page is the vessel. The page does not add marketing language around the paper.
- At most one CTA, at the very bottom.
- May include figures, tables, and inline citations. No carousels, accordions, or interactive UI beyond anchor navigation.
- Paper's voice may exceed even Architecture in academic register.

**Cross-page linking:** Other Arken pages link to specific anchors within
papers. Every anchor referenced from another page must exist on the target paper.

---

## F — Pilot

A single named pilot, hosted as a page. Pilot pages exist only when
contractually cleared.

**Reader:** Procurement buyer or CEO evaluating whether to commission their own
pilot. Reading to see what an actual engagement looks like end to end.

**Register:** Reserved. The most restrained voice on the site. Reads like an
after-action report.

**Composition:**

1. **Mark Plate** (Hero) — partner name (if cleared) and pilot's one-sentence summary
2. **Scene Set** — 3 moments: the question that prompted the pilot, the moment Arken handled the question, the outcome
3. **Facet List** — 3–4 concrete results: workflows automated, sources approved, decisions on the record, gaps resolved
4. **Two-Column Artifact** — one real artifact from the engagement (heavily anonymised even when partner is named)
5. **Quote block** — one named quote from the partner, if contractually cleared
6. **Mark Plate** (Begin) — *"Request a pilot in your operation →"*

**Constraints:**

- Every claim approved in writing by the partner.
- No statistics that cannot be verified by the partner's own systems.
- No cross-pilot comparisons.
- If partner withdraws clearance for any element, that element is removed within 24 hours.

**Pilot status states:**

| Status | Page exists? | Partner named? | Quote shown? |
|---|---|---|---|
| Pre-disclosure | No | No | No |
| NDA-cleared | Yes | No (anonymised) | No |
| Name-cleared | Yes | Yes | No |
| Full-cleared | Yes | Yes | Yes |

Each pilot's status is recorded in a single source-of-truth field. The page
renders only what the status allows.

---

## G — Form

A single-purpose page that captures a real next-step request.

**Reader:** Has decided to take a next step and is ready to give Arken their
details.

**Register:** Calm, operator-named. Form is the page voice extended into UI.

**Composition:**

Single Mark Plate, with form fields below the lead.

1. Triangle mark, centred
2. Eyebrow: `BEGIN` (or appropriate verb — `DOWNLOAD`, `CONTACT`)
3. H1: the page's promise (*"Bring one workflow that has to hold up."*)
4. Lead: one sentence describing what happens on submit
5. Form: 4–7 fields maximum, operator-named
6. Submit button: clear verb (*"Request the briefing"* not *"Submit"*)
7. Confirmation state: a Mark Plate confirming the action quietly, with a single next-step link

**Constraints:**

- No marketing copy interleaved with the form.
- No checkbox marketing consents framed as required fields.
- No "Get a free trial" or "Talk to sales" language.
- Field labels obey voice rules: *"Your role in the work"* not *"Job title"*.
- Privacy and security disclosures render in mono uppercase, dim, beneath the submit button.
- Confirmation pages do not celebrate. No animation, no marketing CTA to share on LinkedIn.

---

## H — Index

A page that lists all instances of another archetype. `/industries` lists all
Industry pages. `/whitepapers` lists all Papers. etc.

**Reader:** Arrived directly at the index, often from navigation, looking to
browse rather than read deeply.

**Register:** Editorial restraint. Mostly Card Grid with short Mark Plate at
top.

**Composition:**

1. **Mark Plate** (small) — eyebrow, H1 naming the index (*"Industries"*, *"The work"*, *"Papers"*, *"Pilots in motion"*), one-sentence lead
2. **Card Grid** — every page of the underlying archetype, alphabetical or by recency
3. **Mark Plate** (Begin) — closing CTA, generic across the index

**Constraints:**

- No editorial commentary between cards. Index is a catalogue, not an essay.
- Each card on an Index uses the same template across all entries.
- If only one or two entries exist for an archetype, the Index page does not exist. The single entry is linked directly from the homepage or footer.

---

## Cross-archetype rules

### One opening, one closing

Every page opens with a Mark Plate or Chamber Moment and closes with a Mark
Plate. No exceptions.

### One CTA per page maximum

A page has one closing CTA. Inline next-step links allowed mid-page, but only
as text-arrow links, never as buttons.

### One Chamber Moment per page maximum

Only the Flagship and `/architecture` carry Chamber Moments in the body. All
other pages reserve the Chamber Moment for the Hero or do without entirely.

### Voice unlock by depth

The further into the site the reader travels, the more vocabulary unlocks:

| Depth | Vocabulary unlock |
|---|---|
| Flagship | Master verbs and nouns only. No internal terms. No industry-specific terms (except in §Industries card bodies). |
| Industry / Work | Industry-specific vocabulary unlocked. Still no internal terms. |
| Architecture / Paper | Internal vocabulary unlocked, each term defined inline. |
| Pilot | Industry-specific vocabulary unlocked; partner-specific terms only with clearance. |
| Form | Operator-named field labels; no marketing copy. |
| Index | Flagship vocabulary only. The Index speaks to all readers. |

### Consistency across the site

The same word means the same thing across every Arken page:

- *The work* always refers to the reader's actual job.
- *The team* always refers to the actor inside the customer's organization.
- *The source* always refers to an approved document or record.
- *Hold* is always the master verb for defensibility.

If a Lovable-built page uses *the work* to mean Arken's product, the page is
broken.

---

## The archetype test

Before any new page enters the build queue, three questions:

1. **Which archetype is this page?** If none, the page should not exist.
2. **Does the page composition match the archetype's canonical sections?** If not, justify the deviation in writing or rebuild.
3. **Does the page honour the archetype's unique constraints?** If a Pilot page surfaces an unverifiable claim, the page is wrong even if every sentence reads beautifully.

End of document.


============================================================
# Source: .lovable/arken-section-grammar.md
============================================================

# Arken Section Grammar

This document defines the section composition patterns used across all Arken
pages. Each grammar specifies structure, treatment, and what it does not do.

Companion documents:
- `arken-voice-and-vocabulary.md` — language and word choice
- `arken-page-archetypes.md` — which grammars combine into which pages
- `arken-homepage-locked-text.md` — locked exemplar

There are seven section grammars and three minor patterns. No new grammars
without explicit re-lock.

---

## Grammar A — Mark Plate

A section that opens or closes a page. Single editorial moment.

**Structure:**
- Optional triangle mark above
- Eyebrow (mono uppercase)
- H1 or H2 (sans-serif, large)
- Sub (one sentence)
- Optional CTA (text-link with arrow, never a button — except the homepage Hero which has no CTA)

**Used as:**
- Page Hero (every archetype)
- Page Begin / closing CTA (every archetype)
- Index page openers

**Examples on the homepage:**
- §1 Hero
- §14 Begin

**What this grammar is not:**
- Not a content section
- Not used mid-page for routine sections (use Plaque or Facet List instead)
- Never has more than one CTA

---

## Grammar B — Plaque

A short declarative statement section. Mono uppercase commitments stacked or
arranged horizontally.

**Structure:**
- Optional eyebrow above
- 2–5 lines of mono uppercase declarations
- Optional hairline rules above/below
- No body copy
- No CTA

**Used as:**
- Trust Strip
- Section dividers that need editorial weight
- "What we are" / "What we are not" architectural statements

**Examples on the homepage:**
- §2 Trust Strip (four declarations: refuse / source / keep / run)

**What this grammar is not:**
- Not a feature matrix
- Not a comparison table
- Not three columns of cards

---

## Grammar C — Scene Set

A section that presents 2–4 parallel scenes. Each scene composed as a vignette
with consistent column structure.

**Structure:**
- Eyebrow
- H2 (one-sentence claim or question)
- Optional sub (one sentence framing)
- 2–4 scenes, each a three-column composition:
  - Left: Roman numeral + industry/category label (mono uppercase)
  - Middle: Date stamp or opening line (mono uppercase), scene body (serif)
  - Right: Champagne pull-out phrase (serif, larger, right-aligned)
- Italic closer (one sentence, centered or left-aligned)

**Used as:**
- §3 The Strains (homepage)
- Industry page Scene Sets
- Work page Scene Sets

**Constraints:**
- Each scene must have a date anchor, specific situation, and vivid concrete object
- Body column shares a `max-width: 38ch` so scenes share a visual rectangle
- Closing line in italic serif, one sentence only
- No more than four scenes; minimum two

**What this grammar is not:**
- Not bullet-pointed pain points
- Not customer testimonials
- Not case studies

---

## Grammar D — Card Grid

A 2×3, 3×2, or 3×3 grid of cards with consistent template.

**Structure:**
- Eyebrow
- H2
- Sub (one sentence)
- Grid of cards, each:
  - Roman numeral or em-dash label (small, top-right corner)
  - H3 (industry/work name)
  - Body (1–2 sentences)
  - CTA (`READ SOLUTION →` or `LEARN MORE →`, text-link with arrow)

**Used as:**
- §4 Industries (homepage)
- Index pages
- Work-by-Industry sub-grids on Work pages

**Constraints:**
- Cards must share consistent height and treatment
- Hover state: translate(-2px) + subtle box-shadow. No background change. No color shift.
- Hairline border at low opacity (`rgba(20,28,40,.06)`)

**What this grammar is not:**
- Not a feature comparison grid
- Not a pricing tier display
- Not a logo strip

---

## Grammar E — Facet List

A section that enumerates 3–5 facets, each with a label and one-sentence body.

**Structure:**
- Eyebrow
- H2 (one-sentence claim like *"Five facets. One trace."*)
- Sub (one sentence)
- Optional inline link CTA
- 3–5 facets, each:
  - Label (em-dash + uppercase, mono champagne)
  - Body (1–2 sentences, serif)
- Optional accompanying diagram on the right (when paired with a visual like the pentagon)

**Variants:**

**Capability variant:** Used on Industry and Work pages to describe how Arken handles specific work.

**Pillar variant:** Used in §Heart for architectural commitments. Pillars use bolder labels and tighter bodies.

**Phase variant:** Used in §Engagement. Phases connected by dotted line, each with a phase number, name, and body.

**Examples on the homepage:**
- §5 The Chamber (Capability variant + pentagon diagram)
- §9 The Heart (Pillar variant + glowing mark)
- §10 The Engagement (Phase variant + dotted line)

**Constraints:**
- No more than five facets in any single Facet List
- Facets must be conceptually parallel (same level of abstraction)
- If a diagram accompanies, it must be conceptually anchored to the facets (e.g., the pentagon's vertices map to the five facets)

---

## Grammar F — Two-Column Artifact

A section that pairs editorial framing copy with a structured artifact card.

**Structure:**
- Eyebrow
- Two columns:
  - Editorial framing (eyebrow, H2, body, optional inline link)
  - Artifact card (terminal-chrome treatment, monospace content)
- Optional second pair below alternating layout (text on right, card on left)

**Used as:**
- §6 The Receipt + §6.5 The Specimen (homepage — paired)
- Industry page artifact moments
- Work page artifact moments

**Artifact card composition:**
- Browser-chrome header with monospace URI (e.g., `arken://trace/MNT-2031-44`)
- Monospace content block with structured rows:
  - TRACE ID + identifier
  - Question (in plain language)
  - DECISION or REFUSED block
  - SOURCES USED with count
  - EXCLUDED with reason
  - STATUS

**Constraints:**
- Card sits on `--card` background with hairline border at low opacity
- Monospace font for all card content
- No graphics inside the card (no icons, no status badges)
- The artifact is editorial — it represents a real-feeling output, not a screenshot of the product UI
- No partner-identifying details in the artifact content
- No outcome statistics inside the card

**Specimen artifact rules** (apply to all artifact moments across the site):
- No partner identifiers (generic IDs like `MNT-2031-44`)
- No statistics that imply outcomes (e.g., no "reduced errors by 60%")
- Status reads as in-process (`Awaiting review`, `Refusal recorded · routed to review`) not approved/closed
- The reviewer-bound substrate appears by what is missing as much as by what is present

---

## Grammar G — Chamber Moment

The page's emotional climax. Single editorial moment with significant weight.

**Structure:**
- Optional triangle mark above
- Eyebrow
- H2 (large, serif italic on light backgrounds; serif italic in white on dark backgrounds)
- Sub (one sentence)
- Body paragraph or attribution block
- Optional inline link CTA
- Optional footer mark (mono, centered)

**Background:** May be dark (Heart) or light with image (Lineage opening). One
Chamber Moment per page maximum.

**Used as:**
- §9 The Heart (homepage — dark mountain backdrop)
- §8 The Lineage (homepage — cream with hairline)
- §10.5 The Sovereignty (homepage — cream, same treatment as Lineage)
- §8.5 Pull quote (homepage — minimal Chamber Moment, no body)
- Architecture page opening Chamber Moment
- Paper page opening Chamber Moment

**Constraints:**
- Only Flagship and `/architecture` carry Chamber Moments in the body. All other pages reserve Chamber Moment for the Hero or do without.
- No more than one dark-band Chamber Moment per page (the Heart on the homepage is the page's only dark band).
- Sovereignty section in particular must NOT be dark. The Heart is the single climax; a second dark band creates two competing climaxes.

---

## Minor patterns

### Pattern I — Inline Resources

A small block at the end of a section listing 2–3 related resources as
em-dashed labels with text-link CTAs.

**Example on the homepage:** §13 Resources (the "Read deeper" section uses this pattern at full section weight; smaller versions appear elsewhere).

### Pattern II — Bridge Closer

A single italic serif sentence that closes a section before the next begins.

**Examples on the homepage:**
- *"Same break. Three different days."* (closes §3 Strains)
- *"Defensibility is not a feature. It is the architecture."* (between Lineage and Heart — §8.5)

### Pattern III — Top-Right Link

A small text-link CTA in the top-right corner of a section header, used for
"All industries →", "All resources →" navigation to the corresponding Index
page.

**Examples on the homepage:**
- §11 Active Pilots: `All industries →`
- §13 Resources: `All resources →`

---

## Cross-section rules

### One H2 per section

Every section has exactly one H2. No section uses two H2s.

### Hairline rules between sections

Major sections are separated by full-width 1px hairlines at very low opacity
(`rgba(20,28,40,.06)`). The hairline is the section divider — no other
treatment needed.

### Background tone variation

The page uses three background tones:
- `--background` (cream) — default
- `--alt-deeper` (slightly deeper cream/paper) — used sparingly for sections that need to stand apart (e.g., the Sovereignty section sits on a subtle tone variation, not a different color)
- Dark mountain image — used once on the page, for §9 The Heart only

### Vertical spacing rules

Between sections: ~80–96px of vertical padding above and below each section.

Between elements within a section: 24–56px depending on hierarchy.

Sections that get too much padding (>120px on either side) start to break
the descent rhythm. Verify section spacing at production scale.

### No section uses

- Comparison tables
- Pricing grids
- Animated diagrams
- Hero illustrations beyond the homepage Hero
- Stock photography
- Customer logo strips
- Accordion-based content (single accordion on the homepage in §12 is the exception, used for Practical Questions)
- Carousels

---

## Page descent arcs

Different page archetypes use different rhythms of grammars:

**Flagship descent:** Mark Plate → Plaque → Facet List → Scene Set → Facet List → Two-Column Artifact ×2 → Card Grid → Plaque → Chamber Moment → Chamber Moment → Facet List → Chamber Moment → Card Grid → Card Grid → Mark Plate

**Industry descent:** Mark Plate → Scene Set → Facet List → Two-Column Artifact → Card Grid → Mark Plate

**Work descent:** Mark Plate → Scene Set → Facet List → Two-Column Artifact → Card Grid → Mark Plate

**Architecture descent:** Chamber Moment → linear prose with anchors → references → Mark Plate

**Paper descent:** Chamber Moment → linear prose with anchors → references → Mark Plate

**Pilot descent:** Mark Plate → Scene Set → Facet List → Two-Column Artifact → optional quote → Mark Plate

**Form descent:** Mark Plate with form fields below

**Index descent:** Mark Plate → Card Grid → Mark Plate

---

## What this grammar system does not do

- It does not define a CMS schema (that is implementation).
- It does not define design tokens (CSS variables) — those live in the codebase.
- It does not constrain page length (that is voice and substance discipline).
- It does not allow new grammars without explicit re-lock.

If a proposed section does not fit any grammar above, the section is the wrong
shape or the grammar list needs updating. The default is to fit existing
grammars.

End of document.


============================================================
# Source: .lovable/arken-homepage-locked-text.md
============================================================

# Arken Homepage — Locked Text

This is the canonical text of thearken.com homepage. Every section is locked
verbatim. No copy on this page may be changed without explicit re-lock.

Pre-lock files (any older `arken-copy.md`) are deprecated and must not be
referenced. This document and `arken-voice-and-vocabulary.md` are authoritative.

Section numbering matches the descent order. Treatments and grammar references
point to `arken-section-grammar.md`.

---

## §0 — Top banner

Currently not deployed. Reserved for future use when a published paper is
released.

When activated:

- Tag: `NEW`
- Body: "Governing reasoning, not retrieval — the architectural paper."
- Link: "Read the paper →" → `/architecture`

---

## §1 — Hero (Threshold)

**Background:** Cream with descending mountain illustration (the only image
on the homepage).

**Composition:**

- Triangle mark, centered
- Arken wordmark
- Eyebrow: `THE INTELLIGENCE LAYER FOR REGULATED WORK.`
- H1 (sans-serif, large): `Stand on your own intelligence.`
- Sub: `Trust the work. Defend the answer. Keep what was learned.`
- Descent arrow with `DESCEND` label below it
- No CTAs in Hero

**Eyebrow treatment:** Mono uppercase, low contrast, 24px above H1.

---

## §2 — Trust Strip

**Background:** Cream.

**Composition — Top row:**

Three elements in horizontal layout:

- Left: `BUILT IN HALIFAX · FOR REGULATED WORK`
- Center: triangle mark
- Right: `ARKEN INNOVATIONS INC.`

**Hairline rule below the top row.**

**Composition — Four-line declaration block (stacked, centered):**

```
BUILT TO REFUSE, NOT TO INVENT.
BUILT TO SOURCE, NOT TO RETRIEVE.
BUILT TO KEEP, NOT TO STORE.
BUILT TO RUN WHERE YOU SAY IT RUNS.
```

All four lines mono uppercase, same scale, ~1.8 line-height. Centered.

---

## §2.5 — The Loop

**Background:** Cream. Hairline rules above and below.

**Composition:** Three movements with oversized light numerals on the left,
connected by a vertical thread.

**01 — KNOWLEDGE IN.**

> Approved manuals, procedures, records, contracts, and the decisions your team has already made.

**02 — INTELLIGENCE OUT.**

> Source-backed answers, drafted work, completed records, and refusals when the evidence breaks.

**03 — KEPT FOR NEXT TIME.**

> Every correction, review, and decision strengthens the next answer.

**Treatment:** Numerals oversized in light grey. Vertical thread connects all
three. Eyebrow style for the label (`— KNOWLEDGE IN.`), serif body for the
sentence.

---

## §3 — The Strains

**Background:** Cream.

**Eyebrow:** `THE STRAINS`

**H2:** `Most of what slows the work is not the work.`

**Sub:** `Regulated work does not fail loudly. It fails in audit. In cross-examination. In survey. Long after the wrong answer left the screen.`

**Three scene vignettes:**

Each scene composed as three columns:
- Left: Roman numeral + industry label (mono uppercase)
- Middle: Date stamp (mono uppercase) + scene body (serif)
- Right: Champagne pull-out phrase (serif, larger, right-aligned)

**Scene I — Maritime**

- Stamp: `TUESDAY 3 AM OFFSHORE.`
- Body: The main engine is down. The chief engineer needs the gearbox service history. It is in two systems, a binder, and
- Pull-out: *an email thread from March*

**Scene II — Defence-adjacent**

- Stamp: `FRIDAY 4:50 PM.`
- Body: The proposal is due at five. The team is rewriting the past-performance section that won the last contract. The original is on
- Pull-out: *a laptop that left the company in March*

**Scene III — Legal**

- Stamp: `IN MARCH.`
- Body: The senior partner retires. By June, the associate is rebuilding the memo she wrote in 2021. Her matter file is
- Pull-out: *in archives, undigitised*

**Closer (italic serif, centered or left-aligned):**

> *Same break. Three different days.*

---

## §5 — The Chamber

**Background:** Cream.

**Eyebrow:** `THE CHAMBER`

**H2:** `Five facets. One trace.`

**Sub:** `Five operations. One chain back to source. No exceptions.`

**Inline link:** `Explore the platform →` (link target: `/platform` or
`/architecture` — confirm destination exists)

**Five facets (left column) + pentagon diagram (right column):**

The diagram is a pentagon with five vertices labeled (one per facet) and a
center dot labeled `THE TRACE`. Pentagon stroke: 1.5px, opacity 0.8.

**Facet 1 — ASK**

> Answers come back source-backed, scoped to the reviewer, and refusable when the evidence will not hold.

**Facet 2 — DRAFT**

> Briefs, reports, submissions — grounded only in admitted sources, with the review path attached.

**Facet 3 — WORK THE PROCEDURE**

> Move through controlled work step by step. The record is the work.

**Facet 4 — COMPLETE THE FORM**

> Submissions, certifications — filled from sources already cleared by governance.

**Facet 5 — BRING KNOWLEDGE IN**

> New sources clear review and conflict resolution before they reason.

---

## §6 — The Receipt (Refusal)

This section pairs with §6.5 The Specimen below. Both render as terminal-chrome
artifact cards with editorial framing alternating left-right.

**Eyebrow:** `THE REFUSAL`

**H2 (serif italic):** `When the evidence will not hold, the refusal ships too.`

**Body (left column, beneath H2):**

> A refusal is not silence. It names what was missing and what would resolve it.

**Artifact card (right column, terminal chrome):**

Browser-chrome header: `arken://refusal/MNT-2031-51`

Card content (monospace):
```
TRACE · MNT-2031-51

Can we approve the rev. 9 procedure for Unit 3
turbine bearing replacement?

REFUSED
Insufficient evidence on file. Rev. 9 was superseded
by rev. 12. Rev. 12 alignment tolerances are not yet
admitted to this workspace.

WHAT WOULD RESOLVE
  ·  Admit rev. 12 alignment annex
  ·  Reviewer sign-off from named owner

STATUS              Refusal recorded · routed to review
```

---

## §6.5 — The Specimen (Answer)

Pairs with §6 Receipt above. Layout alternates: Specimen has text on left,
artifact on right.

**Eyebrow:** `THE SPECIMEN`

**H2 (sans-serif):** `The answer ships with its work.`

**Body (left column, beneath H2):**

> Every answer Arken returns carries its trace. The sources used, the sources excluded, the review path, the status.
>
> Not a footnote. The artifact itself.

**Artifact card (right column, terminal chrome):**

Browser-chrome header: `arken://trace/MNT-2031-44`

Card content (monospace):
```
TRACE · MNT-2031-44

What caused the repeated turbine vibration events
on Unit 3 between March and May?

DECISION
Bearing alignment drift, confirmed against
maintenance records and inspection history.

SOURCES USED        3 of 4
  ·  Engine manual, rev. 12
  ·  Maintenance record 2031-44
  ·  Inspection history, Unit 3

EXCLUDED            1 · superseded by rev. 12

STATUS              Awaiting review
```

---

## §4 — Industries

**Background:** Cream.

**Eyebrow:** `INDUSTRIES`

**H2:** `Where the answer must hold.`

**Sub:** `Built for industries where being right is the work.`

**Six cards in 3×2 grid:**

Each card composed of:
- Roman numeral (top-right corner)
- H3 (industry name)
- Body (industry-specific operator phrase)
- CTA: `READ SOLUTION →` linking to `/industries/<slug>`

**I — Maritime & fleet operations**
> Engine maintenance, inspection findings, procedure execution — evidence captured at every step.

**II — Defence & aerospace**
> Accumulated intelligence, made reachable — to the right team, in the right region, with the source on file.

**III — Legal & matter work**
> Drafting, research, and review against admitted sources. Exclusions and review path travel with the work.

**IV — Healthcare operations**
> Operational decisions with traceable basis. Role-aware, audit-ready.

**V — Energy & industrial maintenance**
> Turnaround knowledge, asset procedures, risk evidence. Expert correction compounds.

**VI — Enterprise governance**
> A defensible workspace where accumulated intelligence becomes usable across the organization.

**Note on cards → real pages:** Each card must link to an existing industry
page. If any of the six destination pages does not exist, the card is reduced
to four (Maritime, Legal, plus two more confirmed) until missing pages are
built using the Industry Page Builder skill.

---

## §7 — What We Are Not

**Background:** Cream.

**Eyebrow:** `WHAT WE ARE NOT`

**H2:** `Built to stand up.`

**Three cards in horizontal layout:**

**Card 1 — VERSUS SEARCH**
> Search returns documents.
>
> Arken reasons only over what the team has approved. It shows what it left out — and why.

**Card 2 — VERSUS CHATBOT**
> A chatbot has no notion of approval.
>
> Arken refuses outside its authorization. Routes through review when the work demands it.

**Card 3 — VERSUS GENERAL AI**
> A general model reasons over its training.
>
> Arken reasons only over what governance has admitted — and tells you what it excluded, and why.

---

## §8 — The Lineage

**Background:** Cream.

**Composition:** Triangle mark + hairline above, eyebrow, H2 in serif italic
centered, body paragraph centered, attribution block in champagne mono, single
text-link CTA.

**Triangle mark above small hairline rule**

**Eyebrow:** `THE LINEAGE`

**H2 (serif italic, centered):** `Two decades of research. Built for the moment that finally needs it.`

**Body (serif, centered, ~640px column):**

> Arken is built on Goal-Oriented Knowledge Management — defined at Loughborough University in 2004 and refined through two decades of peer-reviewed industrial case studies. The framework is rare. Arken is the first product built to carry it into the work.

**Attribution block (champagne, mono uppercase, centered):**

```
BALAFAS · JACKSON · DAWSON
LOUGHBOROUGH UNIVERSITY · 2004 → 2026
```

**Inline link:** `The full lineage →` → `/whitepapers/lineage` or `/about`
(confirm destination exists)

---

## §8.5 — Pull quote

**Background:** Cream.

**Composition:** Small hairline rule above and below, centered serif italic
between them. No other content.

```
———
Defensibility is not a feature.
It is the architecture.
———
```

This section sits ~200–300px below the Lineage section (not 800px — that gap
is a known prior bug; ensure it stays tight).

---

## §9 — The Heart

**Background:** Dark mountain landscape (this is the only dark band on the
homepage — preserve as the page's emotional climax).

**Composition:** Champagne eyebrow, large serif italic H2 in white, white sub,
glowing triangle mark in the valley, four pillars in champagne below.

**Eyebrow:** `THE HEART` (champagne)

**H2 (serif italic, white):** `The architecture revealed.`

**Sub (white, centered):** `Every output carries the same trace. Built in, not bolted on.`

**Glowing triangle mark, centered in the mountain valley.**

**Hairline rule below the mark, full width.**

**Four pillars (champagne labels, white bodies, in 4-column grid):**

**Source-traceable.**
> Every answer carries the sources used, the sources excluded, and why.

**Reviewer-bound.**
> The review path travels with the work. No bypass.

**Refusable.**
> When the evidence will not hold, Arken says so. That is the answer.

**Audit by design.**
> Every decision recorded. The record is the work.

**Inline link (champagne):** `Read the architecture →` → `/architecture`

**Footer mark (centered, mono, champagne):** `ARKEN.ARCHITECTURE / V1`

---

## §10 — The Engagement

**Background:** Cream.

**Eyebrow:** `THE ENGAGEMENT`

**H2:** `Pilot first. Then the operation.`

**Sub:**
> Arken is not self-serve. It is built into your operation — against your real source material, with your reviewers in the loop.

**Three-phase composition (01 / 02 / 03 with connecting dotted line):**

**01 — PHASE ONE · PILOT**

**A bounded engagement on real work.**
> New reviewers. New sources. The same architecture, extended where defensibility matters.

**02 — PHASE TWO · WAVE**

**Additional workflows. Same pack.**
> New workflows ride the proven pack. The governed workspace scales without diluting its evidence posture.

**03 — PHASE THREE · EXPANSION**

**New domains. Same architecture.**
> New reviewer groups, new sources, new domains — extended where defensibility matters.

---

## §10.5 — The Sovereignty

**Background:** Cream (NOT dark — the Heart is the only dark band on the page).

**Composition:** Same treatment as the Lineage section. Hairline rules above
and below. Centered.

**Eyebrow:** `THE SOVEREIGNTY`

**H2 (serif italic, centered):** `Your knowledge shouldn't have a landlord.`

**Body paragraph 1 (serif, centered):**

> Arken deploys where your work lives. On-premise. Air-gapped. In your private cloud. In your sovereign region.

**Body paragraph 2 (serif, centered):**

> Your data stays where your governance requires it. Your intelligence stays where you can defend it.

**No CTA. No diagram. No image. No card.**

---

## §11 — Active Pilots

**Background:** Cream.

**Eyebrow:** `ACTIVE PILOTS`

**Inline link (top-right):** `All industries →` → `/industries`

**Two card-class moments (stacked or in two-column grid):**

**Card 1**

Eyebrow: `— TIER-1 SHIPBUILDER SUBSIDIARY`

Body:
> A bounded pilot on real maintenance work. Source-traceable answers across procedures, records, and the binder.

Footer: `ACTIVE · CLEARED FOR REFERENCE`

**Card 2**

Eyebrow: `— DEFENCE-ADJACENT OPERATOR`

Body:
> A bounded pilot under NDA. Reviewer-bound outputs across procedure and proposal work.

Footer: `ACTIVE · IDENTITY WITHHELD`

---

## §12 — Practical Questions

**Background:** Cream.

**Eyebrow:** `PRACTICAL QUESTIONS`

**H2 (serif italic):** `What buyers ask.`

**Four accordion items.** First item open by default.

**Where does our data live?**
> Arken deploys where your governance requires. On-premise, air-gapped, in your private cloud, or in your sovereign region. Your data does not leave the boundary you set. Pilot engagements include written data residency commitments before any source is ingested.

**How is hallucination handled?**
> Arken refuses answers it cannot ground in approved sources. When the evidence will not hold, the refusal is the output — recorded, routed for review, and named in terms of what would resolve it. No fabricated citations. No confident guessing. Refusal as first-class output is the architecture, not a feature.

**What does deployment look like?**
> Pilot first. A bounded engagement on real work, scoped to one workflow or domain, with your reviewers in the loop. Then Wave — additional workflows on the proven pack. Then Expansion — new domains, same architecture. Engagement begins with a private briefing.

**Who built Arken, and what is its foundation?**
> Arken is built on Goal-Oriented Knowledge Management, defined at Loughborough University in 2004 and refined through two decades of peer-reviewed industrial case studies by Balafas, Jackson, and Dawson. Arken Innovations Inc. is the first product to carry the framework into regulated work. Built in Halifax.

---

## §13 — Resources

**Background:** Cream.

**Eyebrow:** `RESOURCES`

**Inline link (top-right):** `All resources →` → `/whitepapers`

**H2:** `Read deeper.`

**Three resource cards in single column:**

**Card 1 — BRIEFING PAPER**
> The architecture of defensible AI.
>
> How Arken makes refusal a first-class output and the trace an architectural property — not a feature.
>
> `READ →` → `/whitepapers/architecture-of-defensible-ai`

**Card 2 — THE LINEAGE**
> Goal-Oriented Knowledge Management at twenty.
>
> From the Loughborough thesis to regulated AI. Why organizing knowledge around goals matters more than ever.
>
> `READ →` → `/whitepapers/lineage`

**Card 3 — FIELD NOTES**
> What we learn from the pilots.
>
> Operational lessons from active engagements in maritime and defence-adjacent work, anonymized.
>
> `READ →` → `/whitepapers/field-notes-2026`

**Note:** Each `READ →` link must point to a real published page. If a paper
does not yet exist, remove the card until it does.

---

## §14 — Begin

**Background:** Cream.

**Composition:** Triangle mark centered above eyebrow, large H2, sub, single
text-link CTA.

**Triangle mark, centered**

**Eyebrow:** `BEGIN`

**H2 (sans-serif, large, centered):** `When the answer has to hold up.`

**Sub (centered):**

> Request a private briefing. We walk through how Arken would be built into your operation.

**CTA (centered, text link with arrow, champagne underline):** `Request a private briefing →` → `/request-access`

---

## Footer

**Background:** Slightly deeper cream tone, full width.

**Left column:**
- Triangle mark + ARKEN wordmark
- Body: `Built in Halifax. For work that has to hold.`
- Industries strip: `MARITIME · DEFENCE · AEROSPACE · ENERGY · LEGAL · HEALTHCARE.`

**Center-right columns (four):**

**PLATFORM**
- Overview
- How work moves through Arken
- Governance & authorization
- The trace
- Refusal & knowledge gaps
- Deployment models

**INDUSTRIES**
- Maritime & fleet operations
- Defence & aerospace
- Legal & matter work
- Healthcare operations
- Energy & industrial maintenance
- Enterprise governance

**FOUNDATION**
- The lineage
- The team
- Research & papers
- Halifax

**RESOURCES**
- Briefing papers
- Field notes
- Press

**COMPANY**
- About
- Careers
- Contact

**Bottom strip:**
- Email: `contact@thearken.com`
- Privacy · Terms · Security
- `© 2026 Arken Innovations Inc.`

**Note on footer copy:** The footer geographic line reads "Built in Halifax,"
not "Built in Canada." This has drifted in prior deploys — verify on every
build.

---

## Descent order

Sections appear in this order on the page:

1. §1 — Hero (Threshold)
2. §2 — Trust Strip
3. §2.5 — The Loop
4. §3 — The Strains
5. §5 — The Chamber
6. §6 — The Receipt (Refusal)
7. §6.5 — The Specimen (Answer)
8. §4 — Industries
9. §7 — What We Are Not
10. §8 — The Lineage
11. §8.5 — Pull quote
12. §9 — The Heart
13. §10 — The Engagement
14. §10.5 — The Sovereignty
15. §11 — Active Pilots
16. §12 — Practical Questions
17. §13 — Resources
18. §14 — Begin
19. Footer

The numbering preserves historic section IDs while reflecting actual descent
position. Some §-numbers are out of sequence because they were added after
the original spine was numbered.

---

## What is not on this page (deliberately)

The following content from pre-lock documents (older `arken-copy.md` versions)
is deliberately excluded from the homepage. These items are not gaps. They
are deliberate omissions per the voice lock.

- "8-Layer Knowledge Architecture" table → replaced by the four Heart pillars
  (architectural distillation)
- "Agent Mesh / Multi-Agent Reasoning" → replaced by the five Chamber facets
  (operator-facing translation)
- RBAC, redaction, policy validation, safety thresholds → distilled to
  "Reviewer-bound" + "Audit by design" pillars
- Cloud / Hybrid / On-prem / Air-gapped as a four-quadrant feature matrix
  → replaced by the Sovereignty section's prose
- "How Arken Works" 7-step engineering flow → distilled to the Loop (3
  movements) + Chamber (5 facets)
- 6-bullet "Key Benefits" list → forbidden pattern; replaced by Chamber +
  Heart structural moments
- "Why Arken, Why Now" market-timing argument → made structurally by the
  Lineage section, not stated as a thesis

If a future audit reviews this homepage against the older `arken-copy.md`
file and flags these as gaps, the audit is reading deprecated documentation.
Direct them to this file.

---

## Maintenance

Any change to this file requires explicit re-lock by Sam. The locked text
above is the single source of truth for homepage copy.

End of document.


============================================================
# Source: .lovable/arken-architecture-page-locked-text.md
============================================================

# Arken Architecture Page — Locked Text

This is the canonical text for `/architecture` — the single deep technical
page on the Arken site. Destination for three homepage CTAs ("Explore the
platform," "See refusal & gaps," "Read the architecture") and the footer
Platform column.

**Archetype:** D — Architecture (per `arken-page-archetypes.md`)
**Register:** Dossier. Long-form prose. Section anchors. Citations.
**Reader:** Technical buyer or skeptic — CISO, regulator, academic peer.
**Voice unlock:** Internal vocabulary permitted with inline definitions on
first use.

Every claim is footnoted where sourceable. Every anchor must resolve. The
page is continuous prose, not card grids.

---

## §A1 — Chamber Moment (page opening)

**Background:** Cream with subtle hairline framing. No image.

**Composition:** Triangle mark above, eyebrow, large serif italic H1, sub,
attribution block, descent indicator.

**Triangle mark, centered**

**Eyebrow:** `THE ARCHITECTURE`

**H1 (serif italic, centered, large):**

*Governing reasoning, not retrieval.*

**Sub (centered, ~640px column):**

> A working paper on the architecture of defensible AI for regulated work.
> How the trace becomes architectural property — not feature. How refusal
> becomes first-class output. How governance runs before reasoning.

**Attribution block (champagne, mono uppercase, centered):**

```
ARKEN INNOVATIONS INC.
HALIFAX · 2026 · V1
```

**Descent indicator (small, centered, mono):**

```
Read time — 18 minutes
Sections — 8
```

**Hairline rule below.**

---

## §A2 — Thesis

**Anchor:** `#thesis`

**Eyebrow:** `THE THESIS`

**H2 (sans-serif, large):** `One architecture. Not a stack of features.`

**Body (serif, continuous prose, ~720px column):**

The defining problem of AI in regulated work is not capability. It is defensibility. A regulated organisation can find an answer in seconds; the question is whether that answer will hold up in audit, in cross-examination, in survey, in classification society review. The work fails not when the answer is wrong, but when the organisation cannot show how the answer was reached.

Most AI systems treat defensibility as a feature added to capability. Retrieval-augmented generation grounds answers in documents. Citation layers attach source references. Compliance modules log queries. Each addition mitigates a specific risk. None of them change what the underlying system does.

Arken inverts the relationship. Defensibility is not added to reasoning. It is the architecture from which reasoning is permitted to begin. Every input is scoped to governance before it shapes any output. Every output carries its complete derivation — the sources used, the sources excluded, the review path, the status. When the evidence does not hold, the system refuses, and the refusal is itself a structured output with its own provenance.

This page describes how that architecture is constructed. It is written for the skeptical reader — the CISO evaluating vendor risk, the regulator examining model governance, the academic peer assessing methodological rigor. The claims are specific. The vocabulary is precise. Where claims can be sourced, they are sourced.

The architecture has seven properties: authorisation before reasoning, source-traceable output, refusal as first-class output, gaps as a distinct class of output, audit by design, sovereignty by deployment, and goal-oriented knowledge organisation as the foundational principle. Each is described below. Together they form one architecture — not seven features.

---

## §A3 — Authorisation Before Reasoning

**Anchor:** `#authorisation`

**Eyebrow:** `AUTHORISATION`

**H2:** `Authorisation runs before reasoning, not after.`

**Body:**

In most enterprise AI architectures, authorisation is a post-processing step. The system reasons over an unscoped corpus, generates an answer, then filters the answer against access controls. The reasoning itself has already touched material the requesting user was not authorised to see. The filter prevents disclosure but does not prevent contamination — the answer's structure, vocabulary, and inferences may already reflect material the user cannot legitimately use.

Arken treats authorisation as an architectural layer that runs before any reasoning step. Sources are scoped to the requesting team and region at ingestion, not at query time. When a question enters the system, the set of admissible sources is determined before the reasoning model is invoked. The model never sees material outside the authorised scope; it cannot be contaminated by what it cannot reach.

This property is implemented at what the architecture calls the authorisation layer.[^1] The layer enforces three constraints simultaneously: role-based access (the requesting user's role within the team), regional residency (the data-residency boundary the source belongs to), and source admission state (whether the source has been formally cleared for use in this workspace through governance review).

A consequence of this design is that role and region are conjunctive, not disjunctive. A document admitted to one team's workspace is not visible to another team within the same organisation, even if both teams have the same role permissions. A document admitted within one regional boundary does not cross to another, even when the requesting user has authority in both regions. The architecture enforces this without policy configuration — the constraint is structural.

A second consequence: when authorisation fails, the response is not a hidden filter. It is an explicit refusal with a defined reason. The user knows that material exists outside their scope, and knows what would need to change for the question to be answerable. This is the basis for what later sections describe as refusal-as-output.

[^1]: Internally, this is layer L6 of the nine-layer architecture (see §A9). External users do not need this nomenclature; the property is more important than the label.

---

## §A4 — The Trace

**Anchor:** `#trace`

**Eyebrow:** `THE TRACE`

**H2:** `Every output carries its complete derivation.`

**Body:**

The trace is the artifact that ships with every answer Arken produces. It is not a citation list, not a footnote, not a metadata sidebar. It is the structured record of how the answer was reached — what sources were used, what sources were excluded, what review path the output must follow, and what the current state of that path is.

A trace contains, at minimum:

- A unique identifier (e.g., `MNT-2031-44`)
- The question as posed by the user
- The decision or refusal returned
- The sources used, with counts and identifiers
- The sources excluded, with reasons for exclusion
- The review path the output is on
- The current status of that path

The trace is not generated as a post-hoc explanation of the answer. It is generated *during* reasoning, as the reasoning unfolds. The architecture cannot produce an output without producing a trace; the trace and the output are constructed in the same operation.

This property has three consequences for defensibility:

First, no answer can exist without provenance. A user cannot ask Arken to skip the trace. A reviewer cannot accept an output that does not carry one. The trace is the output.

Second, the trace is queryable. Every trace is stored as a structured object, not an unstructured log. A compliance reviewer can ask: which traces in the last quarter used source X? Which traces excluded source Y? Which traces resulted in refusal? The audit posture is reactive in most systems and active in Arken.

Third, the trace is portable. When an answer is exported — into a brief, a service report, a regulatory submission — the trace exports with it. The artifact that leaves Arken is not a string of text. It is a string of text plus its provenance, structured so that downstream systems can verify the derivation independently.

This is what is meant by the homepage line *"The answer ships with its work."*

---

## §A5 — Refusal as First-Class Output

**Anchor:** `#refusal`

**Eyebrow:** `REFUSAL`

**H2:** `When the evidence will not hold, the refusal is the output.`

**Body:**

In most AI systems, refusal is a failure mode. The system attempts to answer; when it cannot, it returns an error, a hedge, or a fabricated answer that confidently misrepresents the evidence. The user is left to determine whether the answer is real or invented.

Arken treats refusal as a first-class output — a structured response with the same provenance, the same routing, and the same audit posture as any affirmative answer. When the architecture determines that the evidence on file will not support the question being asked, it produces a refusal with the following structure:

- A trace identifier
- The question
- The refusal itself ("REFUSED")
- The reason — a specific explanation of why the evidence does not hold
- A "what would resolve" block — concrete steps that would make the question answerable
- The status — refusal recorded, routed for review

The refusal is not a dead end. It is a routed action item. The reason names what is missing; the "what would resolve" block names what would unblock it; the status carries the refusal into the review queue of whoever can act on it. A refusal in Arken is a request for the team to update its admitted sources, not a polite "I cannot answer that."

This property has implications for the buyer's reasoning about AI risk. The most common failure mode of AI in regulated work — hallucination — is not solved by training, by guardrails, or by fine-tuning. It is structurally precluded by an architecture that produces refusals as readily as answers. Arken cannot fabricate a citation because the citation is constructed from the admitted-source set, not from the model's training data. Arken cannot hedge a confident answer because the architecture distinguishes between *answerable from admitted sources* and *not answerable from admitted sources*, and the second case produces a refusal, not a confident but ungrounded response.

This is what is meant by the homepage line *"That refusal is the product."*

---

## §A6 — Gaps as a Distinct Class

**Anchor:** `#gaps`

**Eyebrow:** `GAPS`

**H2:** `Knowledge gaps are not refusals. They are their own loop.`

**Body:**

Refusal and gap are easily conflated. Both name something the system cannot do. The architectural distinction matters: a refusal says *the evidence on file does not support this question*. A gap says *the question reveals a domain the team's admitted knowledge does not cover, and that domain should be reviewed for admission*.

A refusal is resolved by reviewing the existing sources — admitting a superseded revision, securing reviewer sign-off, expanding scope to a controlled archive. The team's knowledge does not change; the team's access to its own knowledge does.

A gap is resolved by an expert contribution — a subject matter expert adds new material to the admitted-source set, or corrects an existing source, or annotates a domain that was previously unstructured. The team's knowledge changes. The system's future reasoning expands.

Arken handles gaps as their own routed loop, distinct from the refusal loop. A gap detected during reasoning is flagged with a `gapRootSignature` — a deterministic hash of the workspace, project, output, source, and normalised issue key. The signature ensures that the same gap, detected in different sessions, is recognised as the same gap and routed to the same expert reviewer, not duplicated as a new ticket each time.

This property has a second-order effect on the architecture: gaps accumulate. A workspace that processes a thousand questions over a year and surfaces a hundred gaps becomes a workspace whose admitted-source set has been informed by a hundred specific real-world reasoning events. The corpus is no longer a static document set — it is a learning record of where the team's reasoning has demanded growth. This is what the homepage describes as *"Every correction, review, and decision strengthens the next answer."*

---

## §A7 — Audit by Design

**Anchor:** `#audit`

**Eyebrow:** `AUDIT`

**H2:** `The record is the work.`

**Body:**

The standard model of audit treats the record as something produced after the work, for the benefit of an external reviewer. The work happens; the record is reconstructed. The reconstruction is imperfect, contested, expensive, and sometimes impossible.

Arken inverts this relationship. The record is generated during the work, as a structural consequence of the architecture. Every reasoning step, every source admission, every refusal, every gap, every review decision is recorded as it happens. The record is not a reconstruction; it is the operation itself, written down.

This is enforced by the trace (§A4) for individual outputs and by what the architecture calls the audit substrate for system-level events. Together they produce a log of every action that touched governed knowledge — who asked what, what sources were admissible, what was returned, who reviewed it, what they decided. The log is structured, indexed, and queryable.

The implication for regulated organisations is significant. An auditor, a regulator, or a classification society can ask retrospective questions and receive deterministic answers. *Show me every output in Q3 that used source X.* *Show me every refusal that named source Y as missing.* *Show me every decision the reviewer in role Z approved.* The answers are not assembled from logs and best-effort reconstruction. They are queried from the architecture itself.

A second implication: the burden of proof shifts. In a traditional AI system, the burden falls on the operator to demonstrate that an output was legitimate. In an Arken system, the burden falls on the architecture — the trace is either present and complete, or the output never existed. There is no class of "outputs without traces" because such outputs cannot be produced.

---

## §A8 — Sovereignty by Deployment

**Anchor:** `#sovereignty`

**Eyebrow:** `SOVEREIGNTY`

**H2:** `Deployment is part of the architecture, not a delivery option.`

**Body:**

Sovereignty is not a deployment topology selected from a dropdown menu. It is an architectural commitment that the customer's knowledge does not leave the customer's governance boundary. The deployment topology is the technical realisation of that commitment.

Arken supports four deployment topologies, each of which preserves the sovereignty commitment under different operational constraints:

**On-premise.** The full Arken stack — including the orchestrator, the authorisation layer, the memory graph, and the model inference layer — runs on the customer's infrastructure. No outbound data flow. No external API calls. The customer's data never traverses Arken's network. Used by defence, intelligence, and critical-infrastructure customers whose governance requires that no third party host their knowledge.

**Air-gapped.** A specific variant of on-premise in which the system is fully disconnected from external networks during operation. Used in classified environments and post-disaster operational contexts. Air-gapped deployments use customer-hosted open-weight models (rather than externally-hosted Claude or comparable systems) because external API calls are by definition unavailable. The architecture is identical; the model stack is different.

**Private cloud.** The Arken stack runs in the customer's own cloud account (AWS GovCloud, customer-controlled Azure tenancy, customer-controlled GCP project). The customer retains ownership of the infrastructure, the data, and the keys. Arken provides the architecture; the customer provides the substrate.

**Sovereign region.** The Arken stack runs in Arken's infrastructure but pinned to a specific regional boundary (Canada, EU, UK, Australia) per the customer's data-residency requirements. The customer's data never crosses the region. Used by customers whose governance requires regional residency but not customer-managed infrastructure.

The architectural property that matters across all four topologies is that the customer's knowledge and the customer's intelligence remain inside the customer's governance boundary. Arken does not aggregate customer data across deployments. Arken does not train on customer knowledge. Arken does not phone home with telemetry that includes customer content. The deployment topology determines where the boundary sits; the architecture ensures the boundary holds.

This is what the homepage means by *"Your knowledge shouldn't have a landlord."*

---

## §A9 — The Foundation: Goal-Oriented Knowledge Management

**Anchor:** `#lineage`

**Eyebrow:** `THE FOUNDATION`

**H2:** `The architecture is a product of twenty years of research.`

**Body:**

The architecture described above did not begin with Arken. It is the product application of a framework defined at Loughborough University in 2004 by P.J. (Peter) Balafas, supervised by Tom W. Jackson and Ray J. Dawson, and refined through two decades of peer-reviewed industrial case studies.[^2]

The framework is called Goal-Oriented Knowledge Management (GOKM). Its central claim is that knowledge management systems fail when they organise knowledge by structure (documents, repositories, taxonomies) rather than by goal (what the organisation is trying to do). A document repository can grow indefinitely and become less useful with each addition; a goal-oriented organisation of knowledge becomes more useful as it grows, because each addition is contextualised by the goals it serves.

The 2009 PhD thesis applied the framework to three industrial case studies: Danwood (UK distribution), HSBC, and HBOS.[^3] The Danwood case in particular surfaced a finding that has shaped Arken's design: knowledge management systems fail at onboarding when they begin with documents rather than with goals. Asking a new user to upload their knowledge is the wrong first step. Asking a new user to identify their goal — what they are trying to do today — and then surfacing the knowledge relevant to that goal is the right first step.

Arken applies this principle structurally. The system does not present itself as a document repository to be populated. It presents itself as a workspace organised around the work the team is doing. Sources are admitted in the context of the goals they serve. Reasoning is scoped to the goal at hand. Outputs are routed to the reviewer accountable for the goal's success.

The other GOKM finding that shapes Arken: recognition mechanisms sustain expert engagement better than financial incentives. The PhD case studies showed that subject matter experts who contribute corrections, annotations, and source admissions remain engaged when their contributions are recognised structurally — when they can see their influence on the corpus, on subsequent reasoning, on team outcomes — and disengage when their contributions are treated as units of work to be compensated. Arken's Expert Contribution Profile reflects this finding: experts see legacy impact (queries improved, rules firing rate, domain coverage), not raw correction counts.

The full lineage — including the 2004 IRMA paper, the 2009 PhD thesis, and subsequent peer-reviewed industrial applications — is documented in `/whitepapers/lineage`.

[^2]: Balafas, P.J., Jackson, T.W., and Dawson, R.J. (2004). "A Goal-Oriented Approach to Knowledge Management." *Proceedings of the IRMA Conference*, New Orleans, May 2004.

[^3]: Balafas, P.J. (2009). *A Goal-Oriented Framework for Knowledge Management in Distributed Organisations.* PhD thesis, Loughborough University.

---

## §A10 — The Whole

**Eyebrow:** `THE WHOLE`

**H2:** `Seven properties. One architecture.`

**Body:**

The seven properties described above are not seven features. They are one architecture, described from seven angles.

Authorisation before reasoning is what makes the trace meaningful. The trace is what makes refusal structured. Refusal as output is what makes gaps a distinct class. Gaps are what makes the corpus learn. Audit by design is what makes all of the above defensible to external reviewers. Sovereignty by deployment is what makes the architecture viable for customers whose governance precludes external hosting. And goal-oriented knowledge management is the principle that gives the entire architecture coherence — knowledge organised around the work the organisation is doing, not around the documents the organisation happens to have.

A system that has six of these properties is not Arken. A system with five is a different category of product. The architecture is the conjunction, not the union.

This is what is meant by the homepage section called *The Heart*: every output carries the same trace. Built in, not bolted on.

---

## §A11 — References

**Anchor:** `#references`

**Eyebrow:** `REFERENCES`

**H2:** `Citations.`

**Composition:** Standard academic reference list, mono uppercase eyebrow labels, citation entries in serif body, numbered to match footnotes in the text.

```
[1]  Balafas, P.J., Jackson, T.W., and Dawson, R.J. (2004).
     "A Goal-Oriented Approach to Knowledge Management."
     Proceedings of the IRMA Conference, New Orleans, May 2004.

[2]  Balafas, P.J. (2009).
     A Goal-Oriented Framework for Knowledge Management
     in Distributed Organisations.
     PhD thesis, Loughborough University.

[3]  Jackson, T.W. and Dawson, R.J. (2011).
     "Industrial Application of GOKM: Lessons from Danwood,
     HSBC, and HBOS." [add full citation when sourced]

[4]  [Subsequent peer-reviewed industrial applications,
     2012–2024 — full bibliography to be added by author.]
```

**Note for the engineer:** The references block is the page's academic anchor.
Each citation must be verifiable. Where a full citation is not yet available
(notably reference [3] and [4]), the entry should read "Citation pending —
verify with Peter Balafas before publication." Do not invent citations.

---

## §A12 — Closing Mark Plate

**Eyebrow:** `BEGIN`

**Triangle mark, centered**

**H2 (sans-serif, large, centered):** `Request a private architecture briefing.`

**Sub (centered):**

> Architecture briefings are scheduled with our engineering team. Plan on
> ninety minutes. Bring your hardest question.

**CTA (centered, text link with arrow, champagne underline):** `Request the briefing →` → `/request-access?topic=architecture`

**Footer mark (centered, mono, champagne):** `ARKEN.ARCHITECTURE / V1`

---

## Composition notes for the engineer

### Reading length and pacing

The page is approximately 3,800 words. Read time at adult professional pace
is 16–20 minutes. The descent indicator at the top (§A1) tells the reader
what they're committing to. This is honest framing, not a feature claim.

### No card grids

The body of this page is continuous prose. There are no card grids, no
three-column comparisons, no feature matrices, no pricing tiers, no logos.
Section anchors and footnotes are the only navigation primitives.

### Anchor structure

Eight anchors must resolve from external links:

- `#thesis`
- `#authorisation`
- `#trace`
- `#refusal`
- `#gaps`
- `#audit`
- `#sovereignty`
- `#lineage`
- `#references`

The homepage links to `#refusal` (from §6) and the footer Platform column
links to several others. Verify each resolves to its corresponding §A
section.

### Internal vocabulary unlock

This page is the first surface where internal vocabulary is permitted, each
term defined inline on first use. The terms that appear here and are defined:

- *Authorisation layer* (L6 in internal nomenclature, but the layer name is
  what the reader sees)
- *Admitted source* (a source cleared by governance review)
- *Trace* (the structured derivation artifact)
- *gapRootSignature* (the deterministic gap identifier — defined in §A6)
- *Audit substrate* (defined in §A7)

The term *substrate* is permitted here in technical context. The term
*Substrate Charter* is not. The architecture is described as a property
of the system, not as a governance artifact internal to Arken.

### Diagrams

Two optional diagrams may be added without compromising the dossier register:

1. **The trace flow diagram** (§A4): a small architectural diagram showing
   how a question moves from user → authorisation layer → admissible-source
   set → reasoning → trace + output. Caption: "How a trace is constructed."
2. **The deployment topology diagram** (§A8): a small diagram showing the
   four deployment topologies and where the customer governance boundary
   sits in each. Caption: "Where the boundary sits in each topology."

Both diagrams are line-art only, monochrome, no decorative elements. If a
diagram cannot be produced at high quality, the page works without it.

### CTA discipline

Only one CTA appears on the page, in the closing Mark Plate (§A12). Inline
links to footnotes and to `/whitepapers/lineage` are permitted as text-arrow
links. No buttons elsewhere.

### Cross-page linking

This page references three other pages by hyperlink:

1. `/whitepapers/lineage` — referenced from §A9, footnote-style
2. `/request-access?topic=architecture` — referenced from §A12 CTA
3. The homepage — referenced from the page header (back-to-home arrow)

If `/whitepapers/lineage` does not yet exist, the §A9 link should be
suppressed (not stubbed) until the paper is published. The §A9 content
stands on its own; the linked paper is the deeper version.

---

## Maintenance

Any change to this file requires explicit re-lock by Sam. The locked text
above is the single source of truth for `/architecture` copy.

End of document.


============================================================
# Source: .lovable/style-consistency.md
============================================================

# Style Consistency Checklist

Reference card for typography, color, letter-spacing, and CTA styles
across the V3 marketing site. Use this when authoring or auditing any
new section, page, or component.

> **Color is now canonical.** See `docs/color-system.md` for the full spec
> and `mem://design/color-system` for the rule-sheet. The summary below
> is the quick-reference; the doc is the source of truth.

## 0a · Color (canonical — Apr 2026)

Tokens live in `src/index.css :root` (and `[data-theme="dark"]`) and are
exposed in Tailwind as `paper`, `paper-surface`, `paper-raised`,
`ink-{100..10}`, `gold` / `gold-deep` / `gold-soft`, `cta` / `cta-deep`,
`ok`, `warn`, `bad`, `diff-add` / `diff-rm`, `dark-bg` / `dark-fg` /
`dark-accent`.

**Gold appears in:** eyebrow accents, focus rings, primary section
dividers, chart highlight series, active-nav tint (soft 10%), selection
background, editorial corner ornaments, ≤1 accent per industry mark.

**Gold does NOT appear in:** body text, secondary CTAs, footer link text,
industry icon strokes, headlines, generic hover states. Gold-as-text uses
`--accent-gold-deep` (`#B87E00`) only at ≥14px.

**One CTA color** — `--cta-blue` (`#2563EB`) for primary actions, hover
to `--cta-blue-deep`. Never decorative.

**Dark band** uses three colors only — `--dark-bg #14100A`, `--dark-fg
#F5F1E8` (paper-tinted, never pure white), `--dark-accent #F3C745`. These
do not appear on the cream surface.

**Accessibility** — AA floor; AAA target on body copy (default body at
12.4 : 1 already meets it). Do not use `--ink-50` for paragraphs. Do not
use `--accent-gold` as text on paper (1.8 : 1).

> **Quickest path**: use the canonical tokens (CSS classes or Tailwind keys
> below) — they're wired to the same hero spec automatically.

## 0 · Canonical tokens (use these first)

Defined in `src/index.css` (CSS variables + `@layer components` classes) and
mirrored in `tailwind.config.ts` (`type-*` font sizes, `font-ui` / `font-display`
/ `font-mono-ui` families, `tracking-display` / `leading-title` etc.).

| Use case            | CSS class           | Tailwind equivalent                                          |
|---------------------|---------------------|--------------------------------------------------------------|
| Hero / display H1   | `.text-display`     | `font-display text-type-display`                             |
| Section title (H2)  | `.text-title`       | `font-display text-type-title`                               |
| Sub-heading (H3)    | `.text-h3`          | `font-display text-type-h3`                                  |
| Hero / section lede | `.text-lede`        | `font-ui text-type-lede text-muted-foreground`               |
| Subtitle            | `.text-subtitle`    | `font-ui text-type-subtitle text-muted-foreground`           |
| Body paragraph      | `.text-body`        | `font-ui text-type-body`                                     |
| Small body          | `.text-body-sm`     | `font-ui text-type-body-sm`                                  |
| Caption / meta      | `.text-caption`     | `font-ui text-type-caption text-muted-foreground`            |
| Eyebrow / mono UI   | `.text-mono`        | `font-mono-ui text-type-mono text-muted-foreground uppercase`|
| Mono small          | `.text-mono-sm`     | `font-mono-ui text-type-mono-sm tracking-mono-wide uppercase`|

All classes set font-family, size, line-height, tracking, weight, and (where
relevant) `text-wrap: balance` and a `ch`-based `max-width`. Drop them in and
the section matches the hero by construction.

> **Rule of thumb**: there are only **three fonts** on the entire V3 site —
> Inter (UI/body/headings), Lora (display serif accents), JetBrains Mono
> (eyebrows, captions, mock UI chrome). Anything else is a regression.

---

## 1 · Font Stacks

| Role            | Stack (source)                                                     | Resolved via                          |
|-----------------|--------------------------------------------------------------------|---------------------------------------|
| UI / body       | `'Inter',-apple-system,BlinkMacSystemFont,'Segoe UI',sans-serif`   | direct or `.v3-root` override         |
| Display serif   | `'Lora','Iowan Old Style',Georgia,serif`                           | direct or `[style*="Instrument Serif"]` override |
| Mono / eyebrow  | `'JetBrains Mono','iA Writer Mono S',ui-monospace,monospace`       | direct or `[style*="DM Mono"]` override |

**Do not introduce** `DM Sans`, `DM Mono`, `Instrument Serif`, `Newsreader`,
`SF Pro Text`, or `ui-monospace` raw stacks in new code. The override layer
in `src/v3/shared/Layout.tsx` only catches the legacy tokens — anything else
slips through with the wrong fallback.

---

## 2 · Heading Scale (Inter, weight 600)

| Token            | Size                          | Line-height | Tracking      | Use                              |
|------------------|-------------------------------|-------------|---------------|----------------------------------|
| `tx-display-lg`  | `clamp(44px, 5.8vw, 76px)`    | 1.05        | `-0.040em`    | Hero H1 (alternate, weight 700)  |
| Hero H1          | `clamp(40px, 5.6vw, 72px)`    | 1.06        | `-0.032em`    | Homepage hero (weight 600)       |
| `tx-display`     | `clamp(40px, 4.6vw, 60px)`    | 1.06        | `-0.035em`    | Section openers                  |
| `tx-title`       | `clamp(30px, 3.2vw, 42px)`    | 1.12        | `-0.028em`    | Section titles, BentoCard H2     |
| `tx-h3`          | `clamp(22px, 2vw, 26px)`      | 1.25        | `-0.018em`    | Card headlines, sub-sections     |

Always pair headings with `text-wrap: balance` and a measure token. Use the
canonical CSS variables instead of raw `ch` values so line lengths stay
consistent across pages and ultrawide displays:

| Token                  | Value | Use                              |
|------------------------|-------|----------------------------------|
| `--measure-display`    | 18ch  | Hero H1 / large display          |
| `--measure-title`      | 22ch  | Section titles                   |
| `--measure-h3`         | 28ch  | Sub-headings, card titles        |
| `--measure-lede`       | 56ch  | Hero lede / section ledes        |
| `--measure-subtitle`   | 60ch  | Secondary intro copy             |
| `--measure-body`       | 68ch  | Long-form body                   |
| `--measure-narrow`     | 42ch  | Eyebrow, pull-quote              |

Apply via `style={{ maxWidth: "var(--measure-display)" }}` or by using the
matching utility class (`.text-display`, `.text-lede`, etc.) which already
sets the measure for you.

---

## 3 · Body & Lede

| Token          | Size                       | Line-height | Tracking    | Color           |
|----------------|----------------------------|-------------|-------------|-----------------|
| Hero lede      | `clamp(16px, 1.35vw, 19px)`| 1.55        | `-0.010em`  | `--v2-ink-80`   |
| `tx-subtitle`  | `19px`                     | 1.50        | `-0.005em`  | `--v2-ink-80`   |
| `tx-body`      | `16px`                     | 1.60        | `0`         | `--v2-ink-80`   |
| `tx-body-sm`   | `14px`                     | 1.55        | `0`         | `--v2-ink-80`   |
| `tx-caption`   | `13px` (weight 500)        | 1.45        | `0`         | `--v2-ink-70`   |

Cap body paragraphs at **54–68ch** for readability. Use `text-wrap: balance`
on ledes and pull-quotes; use `text-wrap: pretty` (or omit) on long paragraphs.

---

## 4 · Mono / Eyebrow / Caption

JetBrains Mono only, weight 500, **uppercase**, letter-spacing `.06em`–`.14em`.

| Token         | Size  | Tracking | Color           |
|---------------|-------|----------|-----------------|
| `tx-micro`    | 11px  | `.06em`  | `--v2-ink-50`   |
| `tx-micro-sm` | 10px  | `.08em`  | `--v2-ink-50`   |
| `v2-eyebrow`  | 11px  | `.06em`  | `--v2-ink-50`   |
| Folio (PLATE) | 10–11px | `.14em`–`.18em` | `--v2-ink-50` |

Mock UI chrome (status pills, step rails, citation badges) inside
Section II bento cards: 8.5–10px, tracking `.06em`–`.12em`, ink-50 to ink-80.

---

## 5 · CTAs

All CTAs use Inter, weight 500, font-size 14px, line-height 1.

| Class             | Padding         | Background          | Border               | Text             |
|-------------------|-----------------|---------------------|----------------------|------------------|
| `v2-btn-primary`  | 14px 22px       | `--v2-gov-blue`     | `.5px rgba(255,255,255,.20)` | `--v2-paper`     |
| `v2-btn-gold`     | 14px 22px       | `--v2-gold`         | `.5px rgba(0,0,0,.10)`       | `--v2-ink-100`   |
| `v2-btn-lg`       | 18px 28px       | (modifier)          | (modifier)           | (modifier)       |
| `v2-btn-link`     | 14px 4px        | transparent         | bottom `.5px ink-30` | `--v2-ink-100`   |
| `v2-link`         | inline          | transparent         | bottom `.5px blue-30`| `--v2-gov-blue`  |

Pair a primary button with a `v2-btn-link` (never two filled buttons).
Arrow glyph is a literal `→` after the label, with one space — never an icon
component.

---

## 6 · Quick audit commands

```bash
# Find any rogue font in a file
rg "fontFamily" src/v3/pages/<File>.tsx | grep -v "DM Sans\|DM Mono\|Instrument Serif\|Lora\|Inter\|JetBrains"

# Confirm CTAs use the canonical classes
rg "<Link.*className" src/v3/pages/<File>.tsx | grep -v "v2-btn\|v2-link"
```

---

## 7 · Common pitfalls

1. **Hard-coding `'Inter','SF Pro Text',...` stacks** — these bypass the
   `.v3-root [style*="DM Sans"]` override, producing a different fallback
   chain than the rest of the page. Use `'DM Sans',sans-serif` or one of
   the `tx-*` classes instead.
2. **Forgetting `text-wrap: balance`** on display headings — leaves orphaned
   words on wide viewports.
3. **Using `<br />` for layout breaks** — only acceptable on the hero H1.
   Everywhere else, rely on `max-width` in `ch` units.
4. **Two filled CTAs** — always pair primary + link.
5. **Lede paragraphs wider than 68ch** — readability collapses past that.