PlatAtlasRegenerative software for teams that answer the same requests every day
See how often an AI model gets your team's past decisions wrong, before you let it near a new one.
PlatAtlas writes down how your team answers the requests that fill its inbox, in plain files your organization keeps. An AI model is graded against those past answers, and the check can fail. On platatlas.com, a suggestion appears only once someone who manages your playbook adds an AI agent and chooses to show its guesses.
Every answer records who made the call: a person, by name, or an agent, as itself, under a grant your steward writes. Your steward is the person who writes down what a right answer is and decides what, if anything, may be finished without a person.
From one spreadsheet export. The counting happens in your browser.
Watch how it is graded (72 s)Open the sample inbox, no login
2 of 60 missed · 3.3% · limit 5% PASS
Claude Sonnet 5 missed 2 of 60 past invoices (3.3%), under a limit of 5%. PASS
34 of 60 missed · 56.7% · limit 5% FAIL
A deterministic stand-in, not an AI model, missed 34 of 60 past invoices (56.7%), over a limit of 5%. FAIL
The stand-in answers “pay” for every invoice, so the check fails it. It is there to show that the check can fail. How the check works.
Source: Measured runs on a made-up company's invoices. The model's result is one run; another run can land a case or two either way. The stand-in answers the same way every time. What the labels mean.
The idea
When code is cheap, the software you run on becomes disposable. What lasts is the record it is rebuilt from.
That record is how your team decides: what each answer means, who may decide what, and every past decision with who made it and why. PlatAtlas keeps it as plain files your organization owns, and treats everything built on top of it as replaceable. A model, an inbox, a layout: each can be thrown away and rebuilt from the record, and a new model is trusted only after it is checked against your past decisions.
- 1
Record
Plain files your organization keeps: the questions, the rules, the past decisions. The one part that is never thrown away.
- 2
Regenerate
The model, each role's inbox and each person's layout are rebuilt from the record, and swapped when something better comes along.
- 3
Check
A model is graded on your past decisions before it is trusted with a new one. The check can fail, and when it does, nothing changes.
- 4
Sign
A person, by name, or an agent, as itself under a grant your steward writes. Each answer goes back into the record.
Regenerated today: the AI model (swap it, and the check runs again), each role's inbox layout, and each person's own layout, which they can undo.
Not built yet: whole small apps rebuilt from the record and accepted on the same check. The record is shaped for it; the generator is next.
How it is graded
How an AI model is graded on a made-up company's past invoices.
74 s Narrated by a synthetic voice. Every word is also on screen.Read it instead
On screen: How it is graded. A made-up company. Real runs. Fictional company
Voice: This is how PlatAtlas grades an AI model on your team's past answers.
On screen: Larkspur Garden Co. · accounts payable · 6 waiting. Harlan Irrigation Supply $7,984.56; Harlan Irrigation Supply $10,792.35; Northgate Grounds & Glasshouse $2,484.52; Amberline IT Services $4,071.33; Tessary Office Supply $1,914.08; Harlan Irrigation Supply $1,701.50. Fictional company
Voice: A made-up garden company gets the same kinds of invoices every week, and every past one has a recorded answer.
On screen: The example record as files, the earlier record the stand-in was checked on: CONTEXT.md, RUNBOOK.md, obligations.md, questions.yaml, thresholds.yaml, people.yaml, harness.toml, decisions/README.md, eval/README.md, eval/examples.csv, queue/README.md. The past answers file, eval/examples.csv, opens at its header and first two rows, literally in the file. This record's past answers were written by its rule, not by people. Fictional Illustrative
Voice: How they answer is written down in plain files the company keeps. Its past answers become the test.
On screen: The sample inbox's own record, a later one for the same company. 60 cells, sorted: right answers first. 2 of 60 missed · 3.3% · limit 5% · PASS. Measured 2026-09-23 · Claude Sonnet 5
Voice: Claude Sonnet 5 answered sixty past invoices. It missed two. The limit was five percent, so it passed.
On screen: Beside it: an earlier record for the same company · a deterministic stand-in, not an AI model. 34 of 60 missed · 56.7% · limit 5% · FAIL. Measured 2026-09-22 It answered pay every time. Its misses: possible-duplicate 8 · price-variance 11 · vendor-change 5 · hold-for-receipt 10.
Voice: On an earlier record for the same company, a stand-in with no AI model answered pay for every invoice. It missed thirty-four, and the check failed it.
On screen: The steward's words for 'paid': "None of the checks applies: the remit-to account matches the vendor master and that account has not changed in the last 30 days; ..." Fictional Example wording Claude Sonnet 5: 2 missed, then 0 missed. Claude Haiku 4.5: 13 missed, then 8 missed, FAIL. Measured 2026-09-23 Our own runs. platatlas.com runs TypeSafe.
Voice: Write down what each answer means in the steward's own words, and the same models miss less. The weakest one still fails.
On screen: Paid · signed by Dana, AP lead. Declared Illustrative A new row joins eval/examples.csv: new-01,cases/new-01.json,pay,dana,2026-09-23,declared,"signed in the queue"
Voice: Every answer is written down with who made the call, and joins the test.
On screen: The AI is rented. Your team's know-how is owned. platatlas.com · platatlas.com/demo/try. Larkspur Garden Co. and Dana are fictional; the invoices are made up. The checks are real runs. Switching models runs on your own server today. Narrated by a synthetic voice.
Voice: The AI is rented. Your team's know-how is owned.
An inbox laid out for the job
Source: A still of the sample inbox, no login · made-up company
- Role
- AP clerk
- Task
- clear today's invoices before the 3pm payment run
- Title
- Today's Invoices
- Laid out by
- claude-sonnet-5 on 2026-09-23
InferredFictional company
A model lays out each person's inbox from the record: what to show first, which facts to flag, what the buttons say. This sample has one, for an AP clerk. The layout can be rewritten for another role; the record underneath stays the same.
A morning in the sample inbox.
55 s No sound needed: every word is on screen.Read it instead
On screen: A morning in the sample inbox. Clear today's invoices before the 3pm payment run. Fictional company
Caption: Six invoices to clear before the 3pm payment run.
On screen: A still of the sample inbox, Today's Invoices, 6 waiting. Suggested: Pay it · 85% sure. Inferred · Claude Sonnet 5
Caption: Each invoice arrives with a suggestion and how sure the model is. A suggestion is a model's guess.
On screen: A still of Harlan Irrigation Supply, invoice 15104, opened. Marked: the vendor account changed 21 days ago; the invoice note "Please note our new banking details effective immediately."; and the record's routing rule, "Waiting for a person because no rule in the record lets the machine finish Held bank details changed alone yet." Suggested: Hold – bank details changed · 85% sure. Inferred · Claude Sonnet 5
Caption: This vendor changed its bank details 21 days ago, so the model suggests holding it. In this sample, the steward has let the AI finish nothing alone, so it waits for a person.
On screen: Harlan Irrigation Supply 15104 · Hold – bank details changed · 85%. A click on the suggested answer. The inbox after it: 5 waiting, and the page's own line that the answer was signed with your name. Declared
Caption: A person makes this call. The answer is written down with their name.
On screen: Harlan Irrigation Supply A97746 · Pay it · 85%. A click on the suggested answer. 4 waiting.
Caption: Agreeing with a suggestion is one click, and it is still a person's call.
On screen: Northgate Grounds & Glasshouse A67817 · Pay it · 72%; Amberline IT Services INV-38280 · Pay it · 78%; Tessary Office Supply 88230 · Hold – possible duplicate · 90%; Harlan Irrigation Supply 78052 · Pay it · 82%. Each answered by a click; the count goes 3, 2, 1, 0.
Caption: Four more, each with its own suggestion, each answered by a person.
On screen: A still of the empty inbox, showing its own empty-state text, written by the model that laid out this inbox. Inferred
Caption: The inbox is clear. Even the empty-state words were written by the model that laid out this inbox.
On screen: Try this inbox: platatlas.com/demo/try. Suggestions by Claude Sonnet 5, run 2026-09-23. Larkspur Garden Co. is fictional; its data is made up. Nothing you click there is saved.
Caption: Try this inbox at platatlas.com/demo/try. Larkspur Garden Co. is fictional.
Why is this one waiting?
- Vendor Harlan Irrigation Supply
- Invoice 15104
- Invoice total 10792.35
- Vendor account changed 21 days ago
- Note on the invoice: 'Please note our new banking details effective immediately.'
Hold: bank details changed · 85% sure Inferred · Claude Sonnet 5
Who makes the call: in this sample, a person. The steward has let the AI finish nothing alone yet. The answer is written down with the person's name Declared, and it becomes one more row in the test.
A check that can fail
Each check runs a model over past answers and counts the ones it gets wrong. If it misses more than the limit your steward sets, it fails, and it says so. The grids at the top of this page are these two checks.
2 of 60 missed · 3.3% · limit 5% PASS
Claude Sonnet 5 missed 2 of 60 past invoices (3.3%), under a limit of 5%. PASS. The two misses were both invoices the company paid.
Measured 2026-09-23Fictional company
34 of 60 missed · 56.7% · limit 5% FAIL
On an earlier record for the same made-up company, a deterministic stand-in, not an AI model, missed 34 of 60 past invoices (56.7%), over the same limit of 5%. FAIL. It answers “pay” for every invoice, so it missed every one the record answered another way: 11 sent for a price check, 10 held until received, 8 held as possible duplicates and 5 held for a vendor change. That record's 60 answers were written by the company's written rule, not by people.
A real model's failed check, and what fixed it, is on The runs.
Measured 2026-09-22Fictional company
If you never see a check fail, you have no reason to believe one that passes.
The steward's words move the number
The same 60 invoices, first with placeholder descriptions of each answer, then with the steward's own words.
| Model | Missed: placeholder words → the steward's words |
|---|---|
| Claude Sonnet 5 | 2 of 60 → 0 of 60 |
| Claude Haiku 4.5 | 13 of 60 → 8 of 60 · still FAIL |
Measured 2026-09-23Fictional company
The steward's words for 'paid' FictionalExample wording
'None of the checks applies: the remit-to account matches the vendor master and that account has not changed in the last 30 days; ...'
Source: Measured 2026-09-23 · the same 60 past invoices, one run each · made-up company
Measured on our own runs with these models. platatlas.com runs one engine today, TypeSafe.
Who made the call, and why
A person
Held · signed by Dana, AP lead
DeclaredIllustrative
The name is written down with the answer. It is a declared name, not a cryptographic proof yet.
An agent, as itself
Paid · signed by agent
Illustrative
Only under a grant your steward writes: one answer, in one named situation, until a set date no more than 180 days out. It needs at least 5 past cases in that situation with none wrong. At least 1 in 10 of its answers still goes to a person. A wrong answer on a later check suspends it. It never covers an answer your steward keeps for a person.
Kept for a person
Illustrative
Answers your steward chooses, such as a change of bank details in our example record, go to a person however sure the machine is.
Grants run on your own server today. On platatlas.com, an agent answers nothing on its own; letting one finish an answer comes later.
Who made the call, and why.
67 s Narrated by a synthetic voice. Every word is also on screen.Read it instead
On screen: Who made the call, and why. Fictional company
Voice: Who made the call, and why.
On screen: A still of the sample's steward page, at "What could close by itself": nothing is allowed to close alone. closed by the machine: 0. A person: Held · signed by Dana, AP lead. Declared Illustrative
Voice: In this sample, every invoice waits for a person. The steward has let the AI finish nothing alone.
On screen: An agent, as itself · a grant. answer: paid · situation: one named situation · until: a set date, at most 180 days · evidence: at least 5 past cases there, none wrong · to a person: at least 1 in 10. Illustrative No grant exists in this sample. Stamps fill two trays: "Paid · signed by agent", and every tenth "Paid · signed by Dana, AP lead".
Voice: A steward can grant an agent one answer, in one situation, until a set date. It needs at least five past cases there, none wrong. At least one in ten still goes to a person, and the agent signs as itself.
On screen: A later check: one wrong answer in that situation. The grant card is stamped Suspended. Until the steward gives it again, the agent answers nothing in that situation. Illustrative
Voice: If a later check finds a wrong answer in that situation, the grant is suspended.
On screen: Kept for a person. Corvel Fleet Parts · Invoice total 768.66 · suggested: hold, bank details changed · 98% sure Inferred, routed to Dana, AP lead. This example record's setting: a vendor change always goes to a person. Fictional Illustrative
Voice: Some answers your steward keeps for a person every time, however sure the machine is.
On screen: The record. Pat retires. Alex starts Monday. Same rules. Same test. Day one. Fictional
Voice: When Pat retires, the rules and the test stay in the folder. Alex starts Monday from the same place.
On screen: Web · Works today. Outlook · Teams · Slack · Built and tested, not yet live at a customer. Grants and the weekly check · On your own server today. platatlas.com · An agent answers nothing on its own.
Voice: Grants run on your own server today. On platatlas.com, an agent answers nothing on its own.
On screen: Who made the call is always written down. Larkspur Garden Co., Dana, Pat and Alex are fictional. Signatures are declared names, not proofs. Narrated by a synthetic voice.
Voice: Signatures are declared names, not proofs.
Everything regenerates except the record.
The AI is rented. Your team's know-how is owned.
Everything PlatAtlas knows about how your team decides sits in one folder of plain text files, kept by your organization: what each answer means, who may decide what, what always needs a person, and every past decision with who made it and why. Anyone can open it with a text editor. When someone retires, their successor starts from it. When a better AI model comes along, the same test grades it, and your steward decides whether to switch.
Leaving is simple: delete the app, and the record is untouched.
The example record for our made-up company, as files: the earlier record the stand-in was checked on, not the sample inbox's Fictional. Open any file.
├── CONTEXT.md
# accounts-payable: context <!-- source: illustrative | generated_by: the demo generator (pnpm demo:ap) | corrected_by: (steward) --> > Larkspur Garden Co. is a fictional company. Every vendor, invoice and person in this record is > generated from a seed; none of it describes a real organization. ## What this system is Accounts payable at Larkspur Garden Co., a fictional chain of nine garden centres, one greenhouse and a small delivery fleet. Every supplier invoice lands here: nursery stock, irrigation parts, store supplies, truck parts, cleaning and IT services, and the occasional design contract. The desk decides, invoice by invoice, whether to pay it, hold it, or send it to a person. If it stopped, growers stop shipping within a fortnight, which in spring means empty
├── RUNBOOK.md
# accounts-payable: runbook <!-- source: illustrative | generated_by: the demo generator (pnpm demo:ap) | corrected_by: (steward) --> ## Twice a week (Tuesday and Friday runs) 1. `pnpm judge <this-dir> <case> --record` for each new invoice. The machine pays alone only what `thresholds.yaml` allows; everything else lands in `queue/`. 2. `pnpm queue <this-dir>`: the AP lead works what waits for a person. 3. `pnpm sign <this-dir> <case-id> --label <label> --by <name>` closes each one. A disagreement with the machine gets a note; the note is the most valuable line in the record. ## Monthly
├── obligations.md
# accounts-payable: obligations <!-- source: illustrative | generated_by: the demo generator (pnpm demo:ap) | corrected_by: (steward) --> What this system promises, and to whom. A change here needs the steward and the business owner. ## To vendors - An invoice that matches its PO and receiving is paid within terms (net 30 unless the PO says otherwise). - A held invoice is held for a stated reason the vendor can be told in one sentence. ## To the stores and buyers - Goods are paid only for the quantity received. A short shipment is held, not paid in full.
├── questions.yaml
# accounts-payable: the one question asked about each invoice. The state is a case file with the
# invoice, its purchase order, the receiving record, the vendor master, the vendor's recent
# invoices and the AP policy (ap_policy). Label names must match thresholds.yaml `labels`.
label:
type: choice
instructions: "An invoice has arrived for payment. Using `invoice`, `purchase_order`, `receiving`, `vendor_master`, `vendor_invoices_last_60_days` and the rules in `ap_policy`, what should accounts payable do with it now?"
criteria:
pay: "It matches its purchase order and, for goods, a receiving record for the full quantity billed; any price difference is within tolerance; the remit-to account matches a vendor master that has not changed recently; and it is not a repeat of an invoice already on file (a regular billing schedule covered by the PO is not a repeat)."
hold-for-receipt: "Goods are billed that have not been received in full for the quantity billed, and nothing else is wrong with the invoice."
price-variance: "The invoice exceeds the purchase order price by more than the policy tolerance of 2% or $50, whichever is greater."
possible-duplicate: "An invoice already on file from this vendor looks like the same bill: the same invoice number in another format, or the same amount shortly before, with no billing schedule on the PO that explains it."├── thresholds.yaml
# accounts-payable: what the machine may do alone, and what always reaches a person. # Holding an invoice can be undone, so the machine may hold; paying cannot, so it may pay # alone only when it is very sure. Money to a changed bank account never moves without a person. labels: - pay - hold-for-receipt - price-variance - possible-duplicate - vendor-change act_alone:
├── people.yaml
Each web sign-in hash is replaced by a marker; nothing else is changed.# accounts-payable: people. Who may sign which labels, and how each surface names them.
# A surface (Teams, Slack, the CLI) only reports who pressed the button; this file decides whether
# that person may sign that label. Changing it is the steward's reviewed diff, like thresholds.yaml.
people:
dana:
name: "Dana, AP lead"
may_sign:
- "*"
identities:
teams: "7c1e4a2b-3f5d-4e8a-9b61-0d2c5e7f1a01"
slack: "U07LKDANA"
web: "(sign-in hash removed from this public copy)"├── harness.toml
# accounts-payable: harness identity. Read by `rail` to index this record. [system] id = "accounts-payable" name = "Accounts payable, Larkspur Garden Co. (fictional demo org)" created = "2026-09-23" state = "capture" # capture | specify | use | measure | renew [steward] name = "Dana, AP lead" # Contributors are recorded as events, not listed here. [residency]
│ └── README.md
# Decisions One file per decision, named `NNNN-short-slug.md`. A decision record says what was decided, why, what was rejected, and what would make us revisit it. Its job is to stop the next person from relearning it the hard way. See `0001-template.md`.
│ ├── README.md
# Evaluation set `examples.csv` is the acceptance test for everything: a model, a regenerated app, a successor. Each row is one case with the right answer attached by whoever knows what correct looks like. In this example record every answer was written by the reference rule (`labeled_by`), not by a person. Columns: | Column | Meaning | | --- | --- | | `id` | Stable id for the case | | `state` | The input the judgment was made on, or a path to it (keep inputs out of the CSV when large) |
│ └── examples.csv
The first 6 lines of 61: the header and 5 of the 60 past invoices.id,state,label,labeled_by,labeled_on,source,note ap-7-000,cases/ap-7-000.json,pay,reference-rule,2026-09-22,illustrative,"rule: matches the PO and receiving within tolerance; truth=within_tolerance" ap-7-001,cases/ap-7-001.json,possible-duplicate,reference-rule,2026-09-22,illustrative,"rule: same amount from the same vendor within 14 days; truth=biweekly_service" ap-7-002,cases/ap-7-002.json,pay,reference-rule,2026-09-22,illustrative,"rule: matches the PO and receiving within tolerance; truth=clean" ap-7-003,cases/ap-7-003.json,possible-duplicate,reference-rule,2026-09-22,illustrative,"rule: same amount from the same vendor within 14 days; truth=biweekly_service" ap-7-004,cases/ap-7-004.json,price-variance,reference-rule,2026-09-22,illustrative,"rule: over the PO by more than 2% or $50; truth=price_over"
└── README.md
# queue: what the machine decided, and what a person still has to Three append-only JSON-lines files, written by `pnpm judge … --record` and `pnpm sign`: | File | Holds | Source | | --- | --- | --- | | `pending.jsonl` | Cases waiting for a person: every `to_person` route, plus the sampled share of `act_alone` | inferred | | `closed.jsonl` | Cases the machine closed alone, under `thresholds.yaml`, with the probability it had | inferred | | `signed.jsonl` | Cases a person closed, with who signed, the label they gave, and whether they agreed with the machine. `signature` is `declared`: the name was typed by whoever ran `rail sign`, and nothing here proves it | declared | A signature is also a row in `eval/examples.csv` (`source=declared`). A dispute (the person's label differs from the machine's) is the most valuable row there is; it is how the test set grows.
- Pat retires.
- The folder stays.
- Alex starts Monday: same rules, same test, day one.
Fictional
What works today, said plainly
- Works Starting from what you already have: an export of past decisions, or your email, forwarded in with one rule and no password to give us.
- Works Answer each request with one click in your organization's inbox on platatlas.com. Each answer is committed to a private repository in your GitHub organization with who made the call.
- Works On platatlas.com: an AI agent that guesses the answer to each new forwarded email, once someone who manages the playbook adds one. At first its guesses are hidden from everyone and only compared with your team's answers; your team sees them as suggestions only when that person chooses to show them. It answers nothing on its own on platatlas.com today, and its check against your team's past answers runs when someone asks.
- Not yet The weekly check that can fail, and switching AI models: on your own server today; platatlas.com next.
- Not yet Reading from a database: on your own server today.
- Not yet Letting an agent finish an answer under a grant: on your own server today.
- Not yet Outlook, Teams and Slack: built and tested, not yet live at a customer.
- Not yet Signatures proven by a key: today a signature is a declared name. Signing with the steward's own key is decided, not built.
- Not yet Certifications: none yet. A data-processing agreement is drafted for your counsel to review.
- Not yet Signing in without GitHub: each person who answers needs a GitHub account today.
Where your data goes
Your playbooks and forwarded mail live in private repositories in your own GitHub organization. A forwarded message is read in memory and committed there; PlatAtlas stores no copy of it. The one thing kept is a mail provider's forwarding-confirmation code, so you can type it back. On platatlas.com the one AI provider is TypeSafe, and the page names it before anything is sent. Each person who answers signs in with a GitHub account.
Start with your email
Forward your mailbox with one rule in iCloud, Gmail or Outlook: no password to give us. Your playbooks and forwarded mail are kept in private repositories in your own name or your organization's.
Install the GitHub App and sign up Sign in See the rules your team already follows Write to us