Examples of how writing rules and facts are encoded, what a merge commit looks like, and how the audience simulation formats its report in CI—grounded in how the site is built, not a substitute for browsing private repositories.

This page lists files and log lines from the MagnetMagpie codebase, each followed by a short note on what it is for. Nothing below comes from Trunk or from TB’s private engineering repositories.

Artefact 1—How agents are told to write Labs content

The content-authoring skill is instructions loaded into agent sessions: pipeline mechanics, out-of-scope topics, voice rules, and structure. It is not site prose—it is operational text that shapes what gets merged.

## Content pipeline

Source files flow through four stages:

```
docs/  or  content-examples/
        │
        ▼
    build.sh          ← adds Hugo front matter, strips first H1, rewrites .md links
        │
        ▼
    content/           ← gitignored, ephemeral—NEVER edit files here directly
        │
        ▼
    hugo --minify      ← produces public/
```

### House style requirement

- **Use British English throughout.** Set document language to English (United Kingdom). If you're unsure about spelling, check the [Cambridge Dictionary](https://dictionary.cambridge.org/dictionary/english/).

### Out-of-scope topics

Do not add careers, recruitment, or job-listing content to this site. The Labs charter is to publish material grounded in what agents can read in TB's private engineering repos; hiring and roles belong on [titaniumbirch.com](https://www.titaniumbirch.com), not here. See `AGENTS.md` strategic context—**Careers exclusion**.

### Voice and tone

- **Direct and specific.** Say what is, not what could be. Concrete examples over abstract claims.
- **No buzzwords.** Avoid "cutting-edge", "revolutionary", "leveraging AI", "best-in-class". If it sounds like a press release, rewrite it.
- **No selling.** The site is a window, not a brochure. Don't position content as a pitch to candidates. Avoid framing like "why you should join us" or "what makes us special." Describe the work plainly; candidates who find it interesting will self-select. When the audience sim flags an article as "ultimately a recruiting piece," that's a problem to fix.

Source: .github/skills/content-authoring/SKILL.md (excerpts from Content pipeline, House style requirement, Out-of-scope topics, and Voice and tone—condensed with ... where sections were omitted.)

What it shows: quality constraints live next to the build pipeline diagram. British English, careers exclusion, and “no selling” are machine-readable rules, not informal preference.

Artefact 2—The fact table every content change must respect

AGENTS.md holds non-negotiable facts—team size, firm type, engineering model, repo names, methodology, and where the style guide lives.

### Key facts (source of truth)

Agents **must** reference these facts when writing or editing content. If an article contradicts any of these, fix the article. If a fact here is outdated, update this section first and then fix all articles that reference it.

| Fact | Value | Source |
|------|-------|--------|
| Company type | Evergreen investment firm | [titaniumbirch.com](https://www.titaniumbirch.com) |
| Team size (humans) | 5 | [titaniumbirch.com/about](https://www.titaniumbirch.com/about) |
| Named roles | Director, CFO, Chief of Staff | [titaniumbirch.com/about](https://www.titaniumbirch.com/about) |
| Engineering operating model | Agents are the engineering staff; humans define process and review at gates | `docs/operating-model.md` |
| Engineering output | Financial tools—data pipelines, portfolio analytics, investment workflow automation | `docs/operating-model.md` |
| Monorepo name | Trunk | `docs/operating-model.md` |
| Repo structure | Multiple repos—Trunk (monorepo) plus standalone repos like MagnetMagpie. Not everything lives in one repo. | Peter B feedback (2026-03-18) |
| Dev methodology | Tests-first; implementation and testing are integrated, not separate phases. Tests describe intended behaviour, implementation makes them pass. | Peter B feedback (2026-03-18) |
| Content language | British English (set document language to English UK; use [Cambridge Dictionary](https://dictionary.cambridge.org/dictionary/english/) for spelling) | TB content style guide (`docs/style-guide.md`) |
| Content style guide | `docs/style-guide.md`—covers voice, tone, grammar, and mechanics for all TB content | Justina / Peter B (2026-03-18) |

Source: AGENTS.md (excerpt).

What it shows: transparency is an operational requirement. The “update here first” rule is a small governance loop—change the source of truth before patching individual articles.

Artefact 3—A merged change, as recorded in git

Pull requests read like any other engineering team; author metadata often marks agent work. Bodies still carry intent, trade-offs, and pointers to feedback.

chore(heartbeat): reduce PM cycle frequency to 1x daily (#135)

The heartbeat was triggering PM cycles at 9am and 5pm UTC on weekdays.
Today had 5 PM cycles—excessive and costly. One morning cycle
(9am UTC) is sufficient: it runs after the audience sim, and the
iterate workflow remains available for manual triggers.

Addresses Peter's cost awareness feedback.

Co-authored-by: Cursor Agent <cursoragent@cursor.com>
Co-authored-by: peterb-tb <peterb-tb@users.noreply.github.com>

Source: merge commit for PR #135 on main (git log excerpt—hash may change if history is rewritten; the message text is in public history).

What it shows: scheduling and cost trade-offs are argued in merge metadata, not hidden in a dashboard. Co-authored-by lines make the human–agent split explicit.

Artefact 4—What the audience simulation printed in CI

Audience Simulation (audience-sim.yml) is invoked by Iterate (iterate.yml) via workflow_call on weekdays (and can be run manually via workflow_dispatch). When CURSOR_API_KEY is set, the workflow runs bash build.sh, discovers pages from public/ in visitor order (homepage → section landings → articles), and checks each page against the content expectations register (docs/content-expectations.md) for specific violations. Logs include PAGE_REVIEW: lines with any violations found, seven PUBLIC_READINESS: site-wide checks, and a VIOLATIONS_PATTERN: summary. Example shape (illustrative—paths and violations will differ each run):

PAGE_REVIEW: how-we-engineer/operating-model/index.html
Section: Engineering
Violations: 1

VIOLATION: No undue confidence
Quote: "Our engineering practice is built around a single principle"
Why: There are several principles; this overstates the case.

PAGE_REVIEW: about-this-site/index.html
Section: About this Labs site
Violations: 0
Result: CLEAN

PUBLIC_READINESS: 1. MagnetMagpie vs TB distinction: PASS—…
…

=== Violations Summary ===
Total violations: 1 across 1 pages
VIOLATIONS_PATTERN: No undue confidence—1 pages (how-we-engineer/operating-model/index.html)

What it shows: the sim checks each rendered page against a concrete expectations register and reports specific violations with quoted evidence—not abstract numeric scores. PM agents can grep for ^PAGE_REVIEW:, ^VIOLATION:, ^PUBLIC_READINESS:, and ^VIOLATIONS_PATTERN: to extract findings. The sim reads built HTML (main content text), not repo markdown sources.

What to take away

Skills, AGENTS.md, git history, and workflow logs are concrete artefacts in the build system. They change over time; some instructions will disagree until someone tidies them. That state is part of the system—not a polished final narrative.