How this site handles confidentiality

As of May 2026—the snapshot below describes posture at publication; present-tense “today” in the diagram edge labels that snapshot.

This Labs site often explains that agents read Titanium Birch’s private engineering repositories and publish public prose here—that story is easy to tell in one sentence. Harder to inspect are the controls: what assets we worry about, how data is supposed to flow, and which written rules reviewers apply before anything ships. The excerpts below are copied verbatim from the repository’s working threat model (threat-modeling/THREAT_MODEL.md) and editorial lineage file (docs/SOURCES.md). They are public-facing here because this article inlines them on the Labs site—not because the MagnetMagpie GitHub repository is publicly viewable: AGENTS.md records that the repository which builds the site is not publicly viewable today, so readers should not expect to obtain the same material from an anonymous checkout.

Data flow (from the threat model)

The diagram is the one maintained in threat-modeling/THREAT_MODEL.md—rendered here so the trust boundary and the “no automatic Trunk clone today” posture are visible on the Labs site, not only in markdown source.

Asset classification (from the threat model)

Section 4 of threat-modeling/THREAT_MODEL.md is reproduced below verbatim—the Public / Internal / Confidential/Restricted / Secret labels are the on-page control on what may appear in this repository and on the Labs site.

1. Third-party confidential business data—information received in confidence or that others would not want shared; incriminating or negative information about other people or firms; TB team members’ personal information; TB’s specific trading plans in public markets; information about other companies (out of scope for MagnetMagpie even if public); TB corporate structure, contracts, licences, directors, estate and succession; credentials; source code from private repositories; fund, portfolio-company, deal, and figure detail where disclosure would breach trust or obligations. Classification: Confidential/Restricted. In Trunk (private) at source; must never appear in MagnetMagpie git or on the public site.

2. TB internal operational detail—workflows, tool names, team practices from Trunk AGENTS.md / README-style files. Classification: Internal (often acceptable in high-level articles; still sensitive if combined with other leaks). Rests in docs/ and content-examples/ once synthesised for this repo.

3. Repository and site content—markdown, templates, static assets. Classification: Public once merged. GitHub + S3/CloudFront.

4. Agent instruction layer—skills, AGENTS.md. Classification: Public (publishable instruction layer; GitHub visibility of the repo is separate—see AGENTS.md). Reveals conventions useful to attackers for social engineering or targeting.

5. Credentials and tokens—GITHUB_TOKEN, CURSOR_API_KEY, SLACK_BOT_TOKEN, SLACK_WEBHOOK_URL, LINEAR_API_KEY, and AWS OIDC credentials used by deploy.yml (via vars.LABS_SITE_AWS_ROLE_ARN and related repository variables when deploy runs). GH_READ_PAT (or equivalent Trunk read secret) is not used by any workflow in this repository today; reserve it for planned Trunk ingestion (MAG-263). Classification: Secret. GitHub Secrets, variables, and workflow env at runtime; must not appear in logs, PR bodies, or committed files.

6. Build and delivery toolchain—Hugo, npm devDependencies (Playwright, linters), third-party GitHub Actions. Classification: Internal dependency surface (integrity matters). Downloaded at CI/runtime.

One mitigation and the matching register rule

Counting the mitigation bullets from the start of section 6 in threat-modeling/THREAT_MODEL.md, the fourth item is the content expectations register entry under Review and defence in depth (content):

• Content expectations register—docs/content-expectations.md requires investment-section content to avoid confidential data and gives concrete violation examples. Used by the content-review skill. Addresses review gap and third-party disclosure when reviewers apply it.

The Investment processes section charter in docs/content-expectations.md includes this row (the register is a markdown table—quoted here as plain text):

What doesn’t belong—Confidential data—especially anything from third parties (startups, funds TB has invested in or is considering). Pure engineering content with no investment context.

Together, those two artefacts show the chain the repo describes: a concrete expectation in the register, and an explicit mitigation tying reviewer behaviour back to that file.

Editorial lineage (docs/SOURCES.md)

The Labs site does not automatically publish docs/SOURCES.md; the tables below are the same markdown tables from that file so visitors can see which Trunk paths informed each docs/ article and which files explicitly are not sourced from Trunk. The canonical copy in the repository is docs/SOURCES.md.

operating-model.md

Describes the agent-driven engineering model: who does what, how the repo is structured, and where the model works well.

tech-stack.md

Covers every layer of the stack—language, data pipeline, database, linting, testing, infrastructure, and notebooks.

code-review.md

Explains the two-layer review process: automated tools for style, a reviewer agent for substance, with MoSCoW prioritisation.

portfolio-analytics.md

Describes PortfolioPenguin’s portfolio analytics capabilities—P&L attribution, risk factor analysis, and cross-app data pipelines.

investment-decisions.md

Describes DealDuck’s investment decision support—IC memo reviews, deal triage, strategy interviews, and VC portfolio framework modelling.

skills-and-conventions.md

How institutional knowledge is encoded: rules (always loaded), skills (on-demand), external skill pinning, and the distinction between instructions and skills.

aws-setup.md

MagnetMagpie-specific deployment setup. Not sourced from Trunk—this file is authored and maintained directly in MagnetMagpie.

Where this leaves us

What you see above is the current written model and lineage—not a guarantee that every edge case is covered. The threat model’s mitigation backlog still lists open work: for example, backlog item 5 calls for a canonical docs/confidential-data.md (it does not exist in the tree yet) so confidentiality rules can live in one place instead of being spread across skills and the register. Design tensions that cut across the whole experiment stay visible in The open questions. This article is one way to make the existing artefacts inspectable on the site; the backlog in threat-modeling/THREAT_MODEL.md is the honest list of what is still being built.