- Updated audit framework with fixed 6-question matrix:
1. 3-Second Rule: understand purpose immediately
2. Three-Step Rule: Input → Processing → Outcome visible
3. Primary Decision: know what to do
4. Information Hierarchy: most important is largest
5. Cognitive Load: what can be removed
6. Call to Action: clear next action
- Added One-Sentence Test:
- Can user describe screen in one sentence?
- Examples for Onboarding, Map View, Dashboard, Results
- Two+ sentences = screen tries to do too much
- Added placeholders for next screens:
- Screen 3: Dashboard (Landvex)
- Screen 4: Map View (Landvex/quiXzoom)
- Screen 5: Results/Decision View (Landvex)
- Priority order: Dashboard → Map View → Results → Search → Settings
- Updated quiXzoom onboarding audit with new matrix format
Rationale: Fixed matrix ensures consistent evaluation across all screens.
One-Sentence Test reveals overloaded screens. Placeholders ready for
next screens. Priority reflects user journey impact.
- EXPERIENCE_AUDIT_QA.md (v1.0, DRAFT):
- Audit framework: 6 questions per screen
- Screen 1: quiXzoom Onboarding — 3s ✅, R→D ⚠️, Decision ✅
- Issue: 'kr' used instead of USD/EUR (Valutaregel violation)
- Issue: Launch date creates hesitation
- Screen 2: Landvex Process — 3s ✅, R→D ✅, Decision ✅
- Issue: Technical terms in step descriptions
- Action items: currency update, date removal, verb simplification
- Next screens: Dashboard, Map View, Search, Mission Details, Results
- COMPONENT_MATURITY.md (v1.0, LOCKED):
- Three levels: Foundation → Validated → Canonical
- Foundation: RFC approved, passes 13 DoD criteria
- Validated: used in 3 real screens, passes Experience Audit
- Canonical: used in 5 screens, 2 sprints stable, other components inherit
- Promotion process with verification requirements
- Current status: all 4 components at Foundation level
Rationale: Observe first, standardize second. Components become Canonical
only after proving value in real screens. Experience Audit identifies gaps
before building components. Maturity model prevents premature standardization.
- FOUNDATIONS-v1.0.md updated:
- Added Landvex Core Principle and Design Constitution to frozen foundations
- Added Core Principle Rules to invariants (2.4)
- Reordered component priority: Modal, Search, Map Panel, Navigation, Table, Data Grid
- Reflects business value: search and maps are central to Landvex
- EXPERIENCE_AUDIT.md (v1.0, LOCKED):
- Four questions for every screen:
1. Can purpose be understood in 3 seconds?
2. Is 'Reality → Decision' visible?
3. Is it obvious what the user should do?
4. Does everything contribute to the decision?
- Three-second rule levels with verification method
- Audit process: select screens → apply questions → prioritize fixes → verify
- Example audit format
- Core Principle Check for RFCs: 4 questions before approval
- COMPONENT_TEMPLATE.md updated:
- Added Core Principle section to template
- Requires: decision support, cognitive load reduction, 3-second understanding
- RFC_DEFINITION_OF_DONE.md updated:
- Added Core Principle as criterion #2 (was 12 criteria, now 13)
- Exit criteria: must pass all 13
Rationale: Freeze foundation with Core Principle as highest authority.
Experience audit ensures all screens support decision-making.
Core Principle Check prevents components that don't serve the user.
Business-value prioritization: search and maps before tables.
- LANDVEX_CORE_PRINCIPLE.md (v1.0, LOCKED):
- Single promise: From reality → decision
- Five steps: Question → Collect → Analyze → Calculate → Decision
- Business verbs, not technical terms
- Three-second rule: 3s/10s/60s understanding levels
- Gauge: Video → AI → Score
- Applies to all communication, UX, documentation, AI
- LANDVEX_DESIGN_CONSTITUTION.md:
- Added §0: From Reality → Decision as highest principle
- Five steps in Swedish
- Three-second rule
- Gauge explanation
- Positioned before Introduction as foundational principle
Rationale: Landvex sells one thing — from reality to decision.
Every screen, illustration, and presentation must follow this flow.
Business verbs make it human. Three-second rule makes it scannable.
Gauge makes it instantly understandable.
Four-point validation:
1. COMPLETENESS ✅ PASS
- All 6 Button states covered
- All 7 Input states covered
- All 10 Select states covered
- All 7 Card states covered
2. ORTHOGONALITY 🟡 PASS WITH NOTES
- 3 minor overlaps identified (surface.raised vs overlay, text.secondary vs muted, action.disabled vs text.muted)
- All resolved by distinct use cases
- 1 ambiguity noted (brand vs action), documented in contracts
3. MINIMALITY 🟡 PASS WITH NOTES
- 9 unused tokens identified
- All justified: needed for upcoming components (Modal, Link, Alert) or dark mode
- No tokens should be removed
4. STABILITY ✅ PASS
- Modal: 0 new tokens needed
- Navigation: 0 new tokens needed
- Table: 0 new tokens needed
- Map Panel: 0 new tokens needed
VERDICT: APPROVE with minor notes. Semantic Color System is stable enough to freeze.
Action items:
1. Freeze Semantic Color System v1.0
2. Update Input, Select, Card to semantic aliases (raise to ~80%)
3. Create Foundation Freeze milestone
4. Proceed with Modal, Navigation, Table, Map Panel
- RFC-002 Input:
- Token Dependencies updated to semantic aliases with primitives
- All tokens now map through color.surface, color.border, color.text, color.status
- No direct color references (e.g., semantic-red-500 → color.status.danger)
- Helper/error text uses semantic tokens
- RFC-003 Select:
- Token Dependencies updated to semantic aliases with primitives
- Dropdown, option, and error states use semantic tokens
- Selected option uses color.action.primary at 10% opacity
- No direct color references
- RFC-004 Card:
- Token Dependencies updated to semantic aliases with primitives
- Surface, border, text hierarchy use semantic tokens
- Shadow tokens mapped to elevation system
- No direct color references
- COMPLIANCE_MATRIX.md:
- Input: 33% → 83%
- Select: 33% → 83%
- Card: 33% → 83%
- All now have Governance ✅, Tokens ✅, Motion ✅, Accessibility ✅, AI ✅
Rationale: Semantic model first. Components never reference primitives.
Token contracts (purpose, allowed, forbidden) ensure correct usage.
Dark mode implementable via token swap without component changes.
- AI_DESIGN_PRINCIPLES.md:
- Restructured into 5 parts: A. Decision Process, B. Component Selection,
C. Token Usage, D. Design Review, E. Escalation
- All rules use RFC 2119 normative words (MUST/MUST NOT/SHOULD/MAY)
- Clearer escalation path: when to create DDR, when to flag uncertainty
- COMPLIANCE_MATRIX.md:
- Tracks readiness for all 29 components (Tier 1/2/3)
- 6 dimensions: Governance, Tokens, Motion, Accessibility, AI, QA
- Foundation documents tracked separately
- Button at 82% (reference for others)
- docs/platform/README.md:
- Reserved directory for cross-cutting governance
- Future: AI Governance, Product Governance, Review Process,
Quality Gates, Release Governance, Decision Frameworks
- Separates platform governance from design system
- LANDVEX_DESIGN_SPECIFICATION.md:
- Button renamed to RFC-001: Canonical Button Component
- Structured with: Cognitive Purpose, When to Use/NOT Use,
User Expectation, Interaction Contract, Failure Behaviour,
Accessibility Contract, AI Contract
- Sets standard for all future RFC component specs
Rationale: AI rules before components (AI writes components).
Compliance matrix makes progress visible. Platform governance
separates cross-cutting concerns from design system. RFC format
for components ensures production-ready specifications.
- Motion System v1:
- Renamed duration tokens from time-based (fast/slow) to intention-based
(instant, interaction, transition, navigation, layout, context-change,
attention, background)
- Updated all component motion tables to use intention-based tokens
- Rationale: AI reasons about purpose, not milliseconds
- Button gold standard (chapter 8.3.1):
- Added RFC-level sections: Cognitive Purpose, When to use/NOT use,
User Expectation, Interaction Contract, Failure Behaviour,
Accessibility Contract, AI Contract
- Sets the bar for all future component specifications
- AI_DESIGN_PRINCIPLES.md (v1.0, LOCKED):
- Core principle: AI must be a design system citizen
- Before-action rules: read hierarchy, check existing, apply New Component Rule
- Token rules: no hardcoded values, semantic first, lifecycle, deterministic
- Component rules: inheritance first, use template, document anti-patterns
- Motion rules: intention-based duration, reduced motion, no decorative animation
- Accessibility rules: WCAG 2.1 AA, no ARIA without purpose
- AI Contract for Button: when to choose Button vs Link vs Icon Button
- RELEASE_DEFINITION.md:
- Defines Landvex Design System v1.0 release gates
- Foundation, Tokens, Foundations, Components (Tier 1/2/3),
Validation, Production
- Current progress: ~55%
- Next milestones: Grid+Elevation, Input/Select/Card, Brand Palette
Rationale: AI rules before components (AI will write components).
Intention-based motion tokens for better AI reasoning. Button as RFC
sets the standard. Release definition creates clear target.
- TOKEN_PHILOSOPHY.md:
- Added Token Lifecycle (Draft → Experimental → Stable → Deprecated → Removed)
- Added Design Review Gate (6 mandatory checks before new token)
- Added deterministic principle: two AI agents must arrive at same token choice
- Restructured into 8 sections with clear hierarchy
- LANDVEX_DESIGN_SPECIFICATION.md:
- Restructured into 4 parts: GOVERNANCE → TOKENS → COMPONENTS → VALIDATION
- Added part headers and updated table of contents
- Aligned with Token Philosophy lifecycle and review gate
Rationale: Governance before values. Prevents uncontrolled token growth
and ensures AI-assisted design development is deterministic and traceable.
Bernt