The Airtool design language, rendered live.
Every section, component and variant the site ships with — shown in its real environment, using the same XSL templates the public pages use. Drift between this page and the public site is impossible : both render from the same components. The companion piece is the editorial canon (forbidden phrases, enforced mechanically at build time) and the competitor design audit (why the visual choices are what they are).
How to read this page
Every section below renders the same component the public site uses. The text above each section names the component ; the text below names the attributes that control its variants.
Editorial canon
87 forbidden phrases / patterns audited at build time. Run .claude/skills/editorial-canon/audit.sh ; build aborts on violation. The canon is the copy guard ; this page is the visual guard.
Competitor design audit
See docs/audits/competitor-design-audit.md for the "airtool.io — the anchor itself" entry. Explains the four signature choices (brand red in Carbon, Geist 300-weight, stat-callout closes, engineering-blog cadence).
Maintenance rule
When you add a new section type to sections.xsl, add one live example here. When you change a component's CSS, this page is the first place to verify the change does not drift.
Brand anchors, in numbers.
The discipline is countable. Every number below is a hard constraint, not a guideline.
Section : <story> — default tone
The default story section. Two paragraphs of prose, no imagery, no list structure. Used for bridge passages between denser components — Apps grid to Comparison table on the home page, for example. Title is optional ; multiple paragraphs supported.
Tone attribute : default (no attribute) renders on white with light-grey body type. The component already sets its background to the alt-grey by default, so no tone="tinted" is needed to soften it.
Section : <story> — tone="dark"
The dark variant. Carbon-black background, near-white body text. Use sparingly — never three dark bands in a row. The page-rhythm rule is one dark band per logical section, with white or tinted content between.
Subtitle and body text are forced to #f4f4f4 on dark backgrounds via the .section--dark override — the default muted-grey would be unreadable on carbon black.
Section : <pillars> — 4-up grid of feature cards
Grid of cards, each with icon, title and body. Used for "four properties" / "what the platform does" framings. 3–6 pillars per block.
One purpose per card
Each pillar says one thing. If a pillar's body grows past four lines, it is two pillars in disguise.
Icon is supporting, not load-bearing
The icon is a visual chip. The title carries the meaning. If the icon and title don't agree, the title wins.
Body in present tense, no apology
The platform owns X. The runtime does Y. Not "we have not yet" or "we are working on". Present-tense statements only.
3–6 per block, even count where possible
Three pillars read as a frame ; four as a grid ; six as a catalogue. Past six, switch to feature-rows.
Section : <strip>
Four-up card row, slightly denser than pillars. Used at the top of a page (just below the hero) as the "four anchors" band — what the page is going to say, in four short statements.
Same shape as pillars
Strip and pillars share visual DNA — both are four-up icon cards. Strip is wider, slightly tighter spacing ; pillars is more breathing room and accepts more body text per card.
Tone attribute
tone="tinted" for the light-grey variant. tone="dark" for carbon black. Default is white.
Always four
Strip is canonically four items. Three reads thin ; five wraps awkwardly. If the content wants five+, it is a pillars block, not a strip.
Section : <comparison> — analyst-deliverable table
3-column comparison with one column highlighted. Reads as "we did the math for you". The highlighted column is always the airtool position.
| A category competitor | Airtool | A second competitor | |
|---|---|---|---|
| Strength | What they're good at, named honestly | ✓ The differentiator, anchored in a verifiable claim | Their honest strength |
| Weakness | Where they fall short, named without apology | ✓ Named honestly — every product has a bound. Canon-respected. | Their honest weakness |
| Buyer fit | Who actually buys this category | ✓ The customer profile this is engineered for | Their actual buyer profile |
| Cost shape | Annual licence + per-seat / per-engine surcharges | ✓ The pricing model — per seat, no per-engine, no premium-feature paywall | Their pricing model |
Section : <feature-rows> — alternating image + bullet rows
One row per capability. Image on one side, copy on the other, alternating left/right. Each feature accepts an optional eyebrow, title, body, image-src and one or more <bullet> children.
One capability per row, breathing space between.
Used on Solutions pages to walk through 4–6 modules in sequence. Each row sits long enough to register before the next one starts.
- Bullets carry the sub-features — Each bullet has a short title (bold) and a body paragraph. Use 3–4 bullets per row.
- Image is supporting, not load-bearing — The image (or placeholder slot) sits beside the prose. The prose carries the meaning.
- Alternation creates rhythm — Row 1 image-left, row 2 image-right, etc. CSS handles the alternation via :nth-child.
The second row alternates to the other side.
When image assets are not yet shipped, the row shows a dashed-border placeholder slot with the row's title as a label. The placeholder is canonical — every Solutions page ships this way until images are captured.
- Placeholder slots are intentional — The dashed border + label is the design — it reads as work-in-progress without being apologetic about it.
- Image specs in the alt-text — Every placeholder carries the capture spec in its alt-text (e.g. 1920 × 1080, 16:9, JPEG q80, ≤ 350 KB).
- Drop-in replacement when ready — Replace the image-src on the <feature> element ; the layout doesn't change.
Section : <pricing-table> — vertical-columns pricing cards
3–4 plan columns, each with name, description, price, unit, feature list and either a per-card CTA or a shared footer. The cards can be made selectable (radio-driven) so a shared footer CTA's href swaps with the selection.
Plan A
A standalone plan
- Feature one — short, factual
- Feature two — a second concrete claim
- Feature three — the third capability
Plan B
Recommended
- Feature one — the recommended scope
- Feature two — included at no extra cost
- Feature three — what the buyer most often wants
- Feature four — the differentiator
Contact us
Project-engineered
- Used when pricing is engagement-dependent
- Not list-priced ; scoped per buyer
Section : <team-grid> — grouped headshot cards
Used on /company/team. Cards group by role family. Bracketed placeholder names + bracketed bio + image-pending placeholder block are the canonical shape until real headshots and approved names land.
Demo group
Each card is a person. Name, role and bio. Headshots are 800 × 800 1:1 JPEG q80 ≤ 150 KB.
[ Name once approved ]
Role · descriptor
[ One- or two-sentence bio once approved. Placeholder text follows the bracket-pattern convention used everywhere on the site for content awaiting sign-off. ]
[ Name once approved ]
Role · descriptor
[ One- or two-sentence bio once approved. ]
[ Name once approved ]
Role · descriptor
[ One- or two-sentence bio once approved. ]
Copy register — what the canon enforces
Forbidden patterns (a partial list — see .claude/skills/editorial-canon/canon.txt for the full 87) : world-class, leading provider, digital transformation, synergies, low-code, drag-and-drop, citizen developer, build apps in hours, seamless, cutting-edge, end-to-end, state-of-the-art, fictional customer names, fictional testimonial bodies, internal SQL table names (sys_*, wic_*), internal Java class names, future-dated unshipped commitments. The audit runs before every build ; the build aborts on violation.
Required register : engineering-direct, present-tense, every claim enumerable, no apologetic backstory. The headline test is — would a senior consultant from Accenture, Deloitte, PwC, KPMG, EY or McKinsey publish this sentence in a customer-facing deliverable ? If no, cut it.
Drift watch — when the design is wandering away from the anchor
If any of the following start appearing, the site is drifting and should be reviewed before shipping : a second accent colour with weight ; illustrations softer than abstract- geometric (cartoons, mascots, friendly mascots-in-disguise) ; stock photography of "happy people in modern office" ; heavy- weight (600+) headline typography ; plan-ladder pricing-page rhetoric ("Starter / Growth / Enterprise" tier names) ; micro- interactions that bounce, perform or auto-play with music ; copy with exclamation marks, "transform", "synergies", "world-class".
The editorial canon catches the copy drift mechanically. The visual drift has no mechanical guard — this page, and the "airtool.io — the anchor itself" entry in docs/audits/competitor-design-audit.md, are it.