Overview · 01 of 03

Six commitments that govern every decision.

The system makes choices on behalf of every advisor working under it. These principles explain what it chooses for, what it refuses, and how to resolve ambiguity when a new situation arises.

01

Working tools, not aspirational design.

Every component documented here is a thing DTTT actually reaches for. Nothing in this system is included because it might be useful, or because it would round out a category. If a pattern appears, it is because it solves a problem that recurs across engagements.

The corollary: when a new client need arises that the library cannot meet, the answer is to extend the library — not to invent something off-system for one engagement.

In practice: refuse decoration. Every visual choice should explain itself in terms of structure, hierarchy, or recognition.
02

Production over presentation.

The system is optimised for fast, AI-assisted production of polished outputs. Patterns are unambiguous. Decision rules are explicit. When two approaches would work, the system picks one and documents why, so that an advisor (or Claude) does not have to deliberate every time.

In practice: when documenting a component, write the decision rule first ("Use this when…"), then the anatomy, then the code.
03

Coherence across containers.

An advisory document opened in Word, an HTML dashboard opened in a browser, a deck in PowerPoint, and an email in Outlook must all read as part of one practice. Container constraints differ; the visual and editorial language does not.

Where a container cannot support a pattern (e.g. interactive disclosure in a Word document), the system documents the structural equivalent — typically a numbered or ruled section — that preserves the same hierarchy.

In practice: every component documents its translation across HTML, Word, PPTX, and email where applicable.
04

Senior-peer voice.

DTTT speaks to destination leadership as an experienced colleague offering guidance — not as a consultant pitching, not as a teacher explaining. The voice assumes intelligence and context. It earns weight through specificity, restraint, and the willingness to take a position.

This is the principle the rest of the editorial system serves. When tone calibration slips, it is almost always because the writing has drifted toward pitching or explaining.

In practice: read every paragraph aloud and ask, would a peer write this? Strip anything that wouldn't survive that test.
05

Free-tier deployable.

Every implementation pattern in the system works on free-tier infrastructure: Netlify free for static deployment, StatiCrypt for password protection where Memberstack is not used, Memberstack for member-gated content, Intercom on the existing DTTT account.

This is a production constraint, not an aesthetic one. It exists because the system must be usable by every engagement without procurement friction.

In practice: if a pattern requires paid infrastructure, the system either provides a free-tier alternative or refuses the pattern.
06

Living infrastructure.

The system is not a one-off design exercise. It is versioned, maintained, and visibly evolving. The whole carries a semantic version. Each component carries its own version, following the precedent of the AI Transparency Framework's eight model versions.

Components are deprecated, not deleted: when a pattern is superseded, the old version remains documented alongside the new one with a deprecation note pointing to the replacement.

In practice: every change ships with a changelog entry. The changelog is a first-class artefact.