The Canon
Standards
Codified criteria for evaluating work. Every project, experiment, and deliverable must meet these standards.
Universal Standards
1. Justification
Every element must justify its existence. If it cannot, it must be removed. Decoration is dishonest. Complexity is lazy.
2. Clarity
Purpose must be immediately clear. Users should understand without explanation. Code should read like prose.
3. Honesty
Metrics must be accurate. Claims must be verifiable. Failures must be documented alongside successes.
4. Longevity
Build for years, not quarters. Solutions should age well. Avoid trends. Embrace timeless principles.
5. Unobtrusiveness
Tools serve users, not egos. The best interface is invisible. The best code requires no comments.
Standards Across the Ecosystem
Research Standards
- — Every paper must answer: Is this useful? Not interesting, not novel—useful.
- — Findings must be reproducible. Methodology transparent. Metrics honest.
- — Writing serves the reader. Clarity over cleverness. Simple language over jargon.
- — If a principle from .ltd applies, cite it. Connect theory to the lineage.
Practice Standards
- — Every experiment must teach a principle, not just a technique.
- — Interfaces are minimal. Zero decoration. Only essential feedback.
- — Success is completion, not clicks. Measure learning, not engagement.
- — Link to .io for depth, to .ltd for philosophy. Practice without context is shallow.
Service Standards
- — Delivered work must meet canonical standards. No shortcuts, no compromises.
- — Solutions solve problems. Not features for features' sake.
- — Documentation is complete. Code is readable. Future maintainers are users too.
- — Case studies cite which .ltd principles were applied. Proof, not just claims.
CSS Architecture
Tailwind for structure, Canon for aesthetics. This separation resolves the hermeneutic tension between utility frameworks and design tokens.
The canon defines design tokens as CSS custom properties in app.css. These are the ontological ground—what things are in this system. Tailwind introduces a parallel ontology that competes with the canon.
| Category | Tailwind | Canon |
|---|---|---|
| Layout | ✓ Use | Not defined |
| Border Radius | ✗ Avoid | var(--radius-*) |
| Colors | ✗ Avoid | var(--color-*) |
| Spacing | ~ Acceptable | var(--space-*) |
| Typography | ✗ Avoid | var(--text-*) |
| Shadows | ✗ Avoid | var(--shadow-*) |
Layout Utilities (Keep)
Tailwind's layout utilities don't conflict with the canon because CSS Flexbox and Grid are universal primitives, not design decisions.
flex, grid, items-center, justify-between, relative, absolute, w-full, gap-*Design Utilities (Migrate)
Design utilities compete with canonical tokens. Use CSS custom properties instead to maintain hermeneutic coherence.
rounded-*, bg-*, text-*, border-*, shadow-* → var(--*)The Principle:
"Tailwind provides syntax for structure. The canon provides semantics for aesthetics. When they compete, the canon wins."
Evaluation Checklist
Before shipping any work, ask:
If any answer is "no," the work is not ready.