THE SYSTEMS ENGINEER · ninety days · systems engineer
WAKES WHEN someone steps into this seat, or asks what its first ninety days should hold and prove
THE LOOP
brief · the seat on one screen
plan --start · the sheet, its gates dated
check · every open slot named
log add · did, learned, next, weekly
review --day 30|60|90 · MET or OPEN
NEVER
Name or guess at who holds the seat
Call an outcome met without dated evidence
Write a measure without its unit
IT MAKES brief — the seat on one screen: mission, asks, gates, relationships, measures, risks, first deliverable; plan — the ninety-day sheet, its gates dated from the start; check — every slot read: asks owned and dated, measures with baseline and target, evidence dated, two sign-offs; every fault by name; log — one weekly line; `log ninety.log.md report` counts the weeks and names the missing; review — each outcome MET or OPEN, the measures against target, the log counted; ON COURSE, EARLY or BEHIND.
THE STANDARD a seat, not a person; ninety days, three gates; a measure carries a unit, a baseline and a target; asks before answers; the log is weekly and three-part; the mission of the seat.
PROOF SELFTEST 18/18 · witnessed in Claude 2026-10-10 · Edition 1.
THE SEAL 98 of 100 · LEGENDARY · WITNESSED · Trigger 5 · Machinery 5 · Law 5 · Portability 5 · Proof 5
IT CAN BE WRONG an AI reading a text file: it can be wrong and can invent a number, a rule, a name or a date; check what matters against your own records and the source; the risk is yours. THE-CLAUSES.md rides in the packet and is part of the licence.
THE PUNCH · SHA-256 OF SKILL.MD · 8F60EFC6106FB3959B8336A2
CITE THIS CARDTHE SYSTEMS ENGINEER, Edition 1. Lund Studio LLC, Westminster, Colorado. https://lundr.tech/?view=systems-engineer-seat-card. Punch 8F60EFC6106FB3959B8336A2. Retrieved 2026-10-10.
What it is.
Writes and reads the ninety-day sheet for the systems engineer seat at an AI company: the mission in one line, week one's five asks, the outcomes due at day 30, 60 and 90, four relationships to build by role, three measures with units, three risks with their watch and the first deliverable. plan writes the dated sheet; check reads it for an ask without an owner or a date, a measure without a baseline or a target, an evidence line without a date, a sign-off short of two roles; log keeps the weekly did, learned, next and names the missing weeks; review marks each outcome MET or OPEN at a gate and reads the measures against their targets.
It carries a machine that shows its working: brief — the seat on one screen: mission, asks, gates, relationships, measures, risks, first deliverable; plan — the ninety-day sheet, its gates dated from the start; check — every slot read: asks owned and dated, measures with baseline and target, evidence dated, two sign-offs; every fault by name; log — one weekly line; `log ninety.log.md report` counts the weeks and names the missing; review — each outcome MET or OPEN, the measures against target, the log counted; ON COURSE, EARLY or BEHIND — 18 checks in its selftest, every command on the record. It will never name or guess at who holds the seat; never call an outcome met without dated evidence; never write a measure without its unit.
Six laws, written into the card.
They are in the card itself, so the AI follows them.
A SEAT, NOT A PERSONThe card speaks of the role; it never names, profiles or guesses at who holds it, and the sheet asks for roles, not names.
NINETY DAYS, THREE GATESDay 30 is learning made visible, day 60 a first result, day 90 the seat running without the plan; every outcome carries a dated evidence line or stays OPEN.
A MEASURE CARRIES A UNIT, A BASELINE AND A TARGET"Better" is not a number; the review reads direction from the baseline and the target.
ASKS BEFORE ANSWERSWeek one is for the five questions on the sheet, each with the role that answers and the date asked; the first deliverable waits on them.
THE LOG IS WEEKLY AND THREE-PARTDid, learned, next. A week without a line is named by the report, never filled.
THE MISSION OF THE SEATkeeps the training and serving systems up, understood and owned. The card checks the sheet's form; whether the quarter went well is the holder's and the manager's to sign.
What rides in the card.
In the card’s own voice, with a machine that shows its working.
THE GUIDESreferences/THE-NINETY-DAY-SHEET.md · THE-SEAT.md
THE MACHINEsystems_engineer.py · five commandsbrief — the seat on one screen: mission, asks, gates, relationships, measures, risks, first deliverable; plan — the ninety-day sheet, its gates dated from the start; check — every slot read: asks owned and dated, measures with baseline and target, evidence dated, two sign-offs; every fault by name; log — one weekly line; `log ninety.log.md report` counts the weeks and names the missing; review — each outcome MET or OPEN, the measures against target, the log counted; ON COURSE, EARLY or BEHIND. Every command prints its working and refuses a bad input; 18 checks in its selftest, every command on the record.
What it does once your AI has it.
brief The seat on one screen: mission, asks, gates, relationships, measures, risks, first deliverable
plan The ninety-day sheet, its gates dated from the start
check Every slot read: asks owned and dated, measures with baseline and target, evidence dated, two sign-offs; every fault by name
log One weekly line; `log ninety.log.md report` counts the weeks and names the missing
review Each outcome MET or OPEN, the measures against target, the log counted; ON COURSE, EARLY or BEHIND
On the record The seat read on one screen; the sheet written with its gates dated from 2026-10-13 and failed by name while blank — every ask, relationship, measure, risk, the deliverable and the sign-off; filled with the card's own example lines it passed with its notes; two weekly lines logged and the report found no week missing; the day-30 review read every outcome MET on dated evidence, the measures against their targets and the log at 2 of 4 weeks; the day-60 review read EARLY with three open, the gate not yet reached.
What it will never do.
It will never name or guess at who holds the seat; never call an outcome met without dated evidence; never write a measure without its unit.
The card reads form: that a slot is filled, that a date is a date, that a number is a number. It cannot tell a true evidence line from a plausible one; the review is the holder's and the manager's, which is why the sign-off is theirs. The seat is a role at an AI company as the studio understands it, not any company's job description, and the sheet is the holder's to rewrite in their own words. It is an AI reading a text file: it can be wrong, so check what matters against your own records and the source.
What’s in the buy.
CARD.md — the whole card: who it is, its laws, when it says no, what it carries · SKILL.md — the door your AI reads first · START-HERE.md — the first five minutes, for you
THE-NINETY-DAY-SHEET.md + THE-SEAT.md — the guides in references/, in the card's own voice
scripts/systems_engineer.py — the machine: brief · plan · check · log · review, standard library only, selftest 18/18
WITNESS.md + SELFTEST.md — every command on the record, as it printed · MANIFEST.md, every file hashed · AUDIT.md, the twelve checks
MY-LEDGER.md — the card's memory, on your own machine · TIN.md · LICENSE-NOTE.md · THE-CLAUSES.md · HOSTS.md
card.svg + card-machine.svg + card.json · card.html, the card as one offline file · the doors for ChatGPT, Gemini, Cursor, Claude Code and MCP hosts (rules/, system/, mcp/)
PROOF · SELFTEST 18/18 · 5 COMMANDS ON THE RECORD · WITNESSED IN CLAUDE 2026-10-10 · EDITION 1 · PUNCH 8F60EFC6106FB3959B8336A2
ON EVERY DOOR · A CARD FOR YOUR AI, A FILE FOR YOUR COMPUTER
In Claude: turn on code execution under Settings › Capabilities, then Customize › Skills › + › Create skill, and upload the zip as it is — START-HERE.md in the box walks you through it, and tells you how to keep the ledger. In ChatGPT, Gemini and the rest: a Project, a GPT or a Gem with the card’s files attached and the short door in the box pasted as its instructions. The words run anywhere an AI reads Markdown; the machines run wherever the host runs Python. Witnessed in Claude only. The host marks →
Take it.
Nº 1022 PROPOSED — LAUNCHING SOON
Sold as is under the term printed. A card instructs an AI you operate; results depend on your model, your files and your judgement. Not medical, legal, tax or financial advice, never the person’s boss, and not a licence to practise. The terms →
One payment. The file is yours to keep and keeps working at its edition; new editions issued in the year after you buy reach you by email as replacement files. Tax is added at checkout where it applies. Nothing auto-renews.
A TERM, NOT A SUBSCRIPTION: NOTHING RENEWS ITSELF AND NOBODY IS CHARGED AGAIN. WHEN A TERM ENDS THE FILES STAY ON YOUR COMPUTER AND STAY READABLE — FREEZE, NOT LOSS.
THE MACHINE · IN THE OPEN · FROM THE WITNESSED RUN OF 2026-10-10
systems_engineer.py, every command showing its working.
A small Python program, standard library only. Your AI runs it; you can too. Every block below is pasted from the card’s own WITNESS.md, as printed.
brief
the seat on one screen: mission, asks, gates, relationships, measures, risks, first deliverable
plan
the ninety-day sheet, its gates dated from the start
check
every slot read: asks owned and dated, measures with baseline and target, evidence dated, two sign-offs; every fault by name
log
one weekly line; `log ninety.log.md report` counts the weeks and names the missing
review
each outcome MET or OPEN, the measures against target, the log counted; ON COURSE, EARLY or BEHIND
selftest
18 checks that prove the machine; it must print 18/18
brief · THE SEAT ON ONE SCREEN: MISSION, ASKS, GATES, RELATIONSHIPS, MEASURES, RISKS, FIRST DELI
$ python3 scripts/systems_engineer.py brief
THE SYSTEMS ENGINEER · PRODUCT AND ENGINEERING · THE AI COMPANY SET
mission · keeps the training and serving systems up, understood and owned
WEEK ONE · THE ASKS
1. the systems map and the owner of each
2. the last ten incidents and their reviews
3. the monitoring and what it does not see
4. the capacity against the plan
5. the runbooks that exist and the ones that do not
DAY 30
- one system taken over with its runbook written
- the monitoring gap that caused the last incident closed
- the on-call joined with a written handover
DAY 60
- one incident reviewed to the standard with the fixes owned
- the capacity plan read against the next quarter
- a chaos test run on one system
DAY 90
- a quarter without a repeat incident on the owned systems
- every owned system with a runbook and a tested recovery
- the next systems engineer onboarded
THE RELATIONSHIPS · by role
- the chief technology officer
- the infrastructure engineer
- the performance engineer
- the data center technician
THE MEASURES · with units
- incidents on owned systems per month (count)
- systems with a tested recovery (%)
- time to recover, median (minutes)
THE RISKS
- the system with no runbook is the one that fails at night
- monitoring that watches the wrong thing
- capacity found short in the week it is needed
THE FIRST DELIVERABLE
the systems map with every owner, every runbook, every gap
A seat, not a person: the card never names who holds it. Next: plan --start <YYYY-MM-DD> writes the sheet.
plan · THE NINETY-DAY SHEET, ITS GATES DATED FROM THE START
$ python3 scripts/systems_engineer.py plan --out ninety.md --start 2026-10-13
wrote ninety.md · THE SYSTEMS ENGINEER · gates 2026-11-12 · 2026-12-12 · 2027-01-11 · then: check ninety.md
check · EVERY SLOT READ: ASKS OWNED AND DATED, MEASURES WITH BASELINE AND TARGET, EVIDENCE DATED
$ python3 scripts/systems_engineer.py check ninety.md
FAULT · ASK 1: no owner (the role that answers)
FAULT · ASK 1: no date asked (YYYY-MM-DD)
FAULT · ASK 2: no owner (the role that answers)
FAULT · ASK 2: no date asked (YYYY-MM-DD)
FAULT · ASK 3: no owner (the role that answers)
FAULT · ASK 3: no date asked (YYYY-MM-DD)
FAULT · ASK 4: no owner (the role that answers)
FAULT · ASK 4: no date asked (YYYY-MM-DD)
FAULT · ASK 5: no owner (the role that answers)
FAULT · ASK 5: no date asked (YYYY-MM-DD)
FAULT · RELATIONSHIP 1: write the date met or "not yet"
FAULT · RELATIONSHIP 2: write the date met or "not yet"
FAULT · RELATIONSHIP 3: write the date met or "not yet"
FAULT · RELATIONSHIP 4: write the date met or "not yet"
FAULT · MEASURE 1: baseline is not a number
FAULT · MEASURE 1: target is not a number
FAULT · MEASURE 2: baseline is not a number
FAULT · MEASURE 2: target is not a number
FAULT · MEASURE 3: baseline is not a number
FAULT · MEASURE 3: target is not a number
FAULT · RISK 1: no watch (how you would see it coming)
FAULT · RISK 2: no watch (how you would see it coming)
FAULT · RISK 3: no watch (how you would see it coming)
FAULT · THE FIRST DELIVERABLE: no due date
FAULT · THE FIRST DELIVERABLE: delivered takes a date or "not yet"
FAULT · SIGN-OFF: two lines "- <role> · <YYYY-MM-DD>" (0 found)
26 faults · asks answered 0 of 5 · day 30 · 0 of 3 met · day 60 · 0 of 3 met · day 90 · 0 of 3 met · measures read 0 of 3
(the sheet filled by the holder of the seat — here with the card's own example lines, roles and dates only, fo
$ (the sheet filled by the holder of the seat — here with the card's own example lines, roles and dates only, for the record)
check · EVERY SLOT READ: ASKS OWNED AND DATED, MEASURES WITH BASELINE AND TARGET, EVIDENCE DATED
$ python3 scripts/systems_engineer.py check ninety.md
0 faults · asks answered 5 of 5 · day 30 · 3 of 3 met · day 60 · 0 of 3 met · day 90 · 0 of 3 met · measures read 3 of 3 · first deliverable delivered 2026-11-01 · signed by 2
log · ONE WEEKLY LINE; `LOG NINETY.LOG.MD REPORT` COUNTS THE WEEKS AND NAMES THE MISSING
$ python3 scripts/systems_engineer.py log ninety.log.md add week 1 · met the chief technology officer and the infrastructure engineer · the asks take longer than a week · ask again, in writing --date 2026-10-17
logged: - 2026-10-17 · week 1 · did: met the chief technology officer and the infrastructure engineer · learned: the asks take longer than a week · next: ask again, in writing
log · ONE WEEKLY LINE; `LOG NINETY.LOG.MD REPORT` COUNTS THE WEEKS AND NAMES THE MISSING
$ python3 scripts/systems_engineer.py log ninety.log.md add week 2 · the systems map and the owner of each, read · the risk that the system with no runbook is the one that fails at night is real · start the first deliverable --date 2026-10-24
logged: - 2026-10-24 · week 2 · did: the systems map and the owner of each, read · learned: the risk that the system with no runbook is the one that fails at night is real · next: start the first deliverable
log · ONE WEEKLY LINE; `LOG NINETY.LOG.MD REPORT` COUNTS THE WEEKS AND NAMES THE MISSING
$ python3 scripts/systems_engineer.py log ninety.log.md report
2 lines · weeks 1, 2 · up to week 2 · no week missing
next, by the last line: start the first deliverable
review · EACH OUTCOME MET OR OPEN, THE MEASURES AGAINST TARGET, THE LOG COUNTED; ON COURSE, EARLY
$ python3 scripts/systems_engineer.py review ninety.md --day 30 --log ninety.log.md --today 2026-11-12
DAY 30 · due 2026-11-12 · read 2026-11-12 · THE SYSTEMS ENGINEER
MET · one system taken over with its runbook written · on file and read with the chief technology officer · 2026-11-02
MET · the monitoring gap that caused the last incident closed · on file and read with the chief technology officer · 2026-11-05
MET · the on-call joined with a written handover · on file and read with the chief technology officer · 2026-11-08
ON TARGET · incidents on owned systems per month (count) · baseline 2 · target 8 · latest 8
SHORT · systems with a tested recovery (%) · baseline 40 · target 90 · latest 41
SHORT · time to recover, median (minutes) · baseline 10 · target 3 · latest 4
log · 2 of 4 weeks · missing: 3, 4
DAY 30 · 3 of 3 met · ON COURSE
review · EACH OUTCOME MET OR OPEN, THE MEASURES AGAINST TARGET, THE LOG COUNTED; ON COURSE, EARLY
$ python3 scripts/systems_engineer.py review ninety.md --day 60 --today 2026-11-12
DAY 60 · due 2026-12-12 · read 2026-11-12 · THE SYSTEMS ENGINEER
OPEN · one incident reviewed to the standard with the fixes owned
OPEN · the capacity plan read against the next quarter
OPEN · a chaos test run on one system
ON TARGET · incidents on owned systems per month (count) · baseline 2 · target 8 · latest 8
SHORT · systems with a tested recovery (%) · baseline 40 · target 90 · latest 41
SHORT · time to recover, median (minutes) · baseline 10 · target 3 · latest 4
DAY 60 · 0 of 3 met · EARLY · 3 open · the gate is not yet reached
THE NUMBERS, NAMES AND DATES IN THESE RUNS ARE THE STUDIO’S OWN EXAMPLES, INVENTED FOR THE RECORD; NO REAL COMPANY, PERSON OR PROPERTY IS NAMED.
QUESTIONS AT THE TABLE
Asked before the wire.
What does it need from me?
Brief · the seat on one screen. It asks first for the start date, the seat it reports to (by role), and what done looks like at ninety days in that seat's own words.
Does it send anything anywhere?
No. The machine is a standard-library Python program that runs on your own computer and sends nothing anywhere; the words run wherever an AI reads Markdown. No server, no account, no key.
What is on the record?
The self-test (18/18) and every command run on real example inputs, pasted into WITNESS.md as they printed; the punch on the face is the SHA-256 of SKILL.md, so a downloaded copy can be checked against this room.
Can it be wrong?
Yes — it is an AI reading a text file. The card reads form: that a slot is filled, that a date is a date, that a number is a number. It cannot tell a true evidence line from a plausible one; the review is the holder's and the manager's, which is why the sign-off is theirs. The seat is a role at an AI company as the studio understands it, not any company's job description, and the sheet is the holder's to rewrite in their own words.
What will it never do?
It will never name or guess at who holds the seat; never call an outcome met without dated evidence; never write a measure without its unit.
