About

Trust Boundary reconstructs infrastructure failures from the primary record. Breaches, outages and architecture faults are all treated as the same kind of event: something was trusted that should not have been, and the boundary was assumed rather than enforced.

The standard

Every technical claim comes from a primary document. Root cause analyses, regulatory consent orders, court filings, vendor post-mortems. Not news coverage of them, and not another explainer's summary.

Sources are listed on every piece, with links where the document is public. If a claim cannot be traced to one, it does not appear. Where a detail is redacted in the source, it stays redacted here rather than being filled in with a plausible guess.

Each piece is checked three times before publication, and the last pass is done against the original documents rather than against the draft.

If something is wrong

Say so in the comments on the video or on X. A correction is added at the end of the article it affects, dated, and pinned on the video. Being corrected in public is the cost of being trusted in public.

Not a security channel

This is written from an infrastructure perspective, not a security research one. Breaches appear as one class of failure alongside outages and architecture faults, and the interest is always in the boundary that was crossed rather than the exploit that crossed it.

Who writes it

Imran Buch. Written independently, drawing only on public incident reports. Nothing here relates to any employer's systems, incidents or vendors.

Elsewhere

YouTube for the videos, X and Instagram for shorter cuts, and RSS for these posts.