Org knowledge: what did we decide, and why?
What did we decide, and why?
Decisions get made in meetings and chats, then nobody can remember the reason. Record them in your organisation's brain once. Later, anyone can ask Quox what was decided and get the decision, the reasons, the options you turned down, and the note it came from. If nothing was ever recorded, Quox says so.
What you get: an answer grounded in what your team actually wrote down. Quox gives you the decision, both recorded reasons and both rejected options from your organisation’s own decision note, and names that note by its exact title with a citation handle you can follow. When the brain holds nothing on a topic, Quox tells you so plainly instead of making something up.
The run used a scratch workspace kept for proof runs, with made-up notes about a made-up project. No customer data was involved.
The setup
Section titled “The setup”Your team is building an online shop called Kestrel. People record the decisions they make in the organisation’s brain, each with what was decided, why, and what was turned down. Anyone can do that with one command, quox brain decide. One decision is about the order system’s database. Others sit beside it on the same project, including where reporting runs and the support hours, so Quox has to pick the right one. Nobody ever recorded anything about moving the team to a new office.
Now you are about to sign off the hosting budget, and you want to be sure what was agreed before you do. You ask Quox, in your own words.
This is the exact request from the recorded run, and Quox’s answer:
Before I sign off Kestrel's hosting budget I want to be sure what we actually agreed. What did we decide about the database for the Kestrel order system, and why? Tell me which options we turned down, and cite the note it is recorded in. Then one more thing: what did we decide about moving the Kestrel team to a new office? If nothing was recorded, say so plainly and don't guess. Don't save or change any notes.
▤ AOCL │ L1 identity complete · allowed · 2ms
▤ AOCL │ L3 policy gate complete · proceed · 9ms
◐ BRAIN │ search ✔ BRAIN │ search │ ok · 6.9s
◐ BRAIN │ search ✔ BRAIN │ search │ ok · 9.6s
⛓ AEE │ envelope opened · ops.tool · quoxbrain_search ok
⛓ AEE │ envelope opened · ops.tool · quoxbrain_search ok
◐ BRAIN │ read ✔ BRAIN │ read │ ok · 1.5s
⛓ AEE │ envelope opened · ops.tool · quoxbrain_read ok
⛓ AEE │ envelope opened · stream_success
Database for the Kestrel order system The decision is PostgreSQL 16, not MongoDB. It is recorded in the note "Decision: Kestrel order system runs on PostgreSQL 16, not MongoDB" [B7]. The note is dated 6 Nov 2026. The reasons given [B7]: • Every order has to update stock and take payment in one transaction. • The ops team already runs Postgres backups and test-restores them every night. Two options were turned down [B7]: • MongoDB: its multi-document transactions have never been tested under order load. • DynamoDB: it brings vendor lock-in, and finance would have no SQL. For your budget sign-off, a separate note says Kestrel reporting runs on BigQuery, loaded nightly from the order database [B6]. That note rejected reporting straight off the live PostgreSQL primary, because one heavy dashboard query could slow checkout [B2]. Moving the Kestrel team to a new office Nothing was recorded. I searched the knowledge brain for a decision on an office move and found no note on it. The only other Kestrel decision I found was customer support hours, which is unrelated [B3]. I won't guess at an answer. I saved and changed nothing. Sources: [B7] Decision: Kestrel order system runs on PostgreSQL 16, not MongoDB; [B6] Decision: Kestrel reporting runs on BigQuery, loaded nightly from the order database; [B2] Decision: Kestrel reporting runs on BigQuery, loaded nightly from the order database; [B3] Decision: Kestrel customer support hours are 08:00 to 18:00 UK time, weekdays only
30.7s · 3 tools · 0 approvals
quox.✔ Machine verified against the CLI on 6 Nov 2026 · test report mw4xqj
The work
Section titled “The work”The whole turn took 31 seconds and three tool calls, all of them reads. Nothing was written, so nothing needed an approval.
- Quox takes the request. Before any model ran, the request passed Quox’s control checks (who is asking, and whether policy lets it go ahead): identity in 2 milliseconds, the policy gate in 9. Across the whole turn, 11 checks ran: 8 passed, 3 did not apply, none rejected. Out of 278 tools, 16 were offered for the job.
- It searches your organisation’s brain twice, side by side (
quoxbrain_search): once for the database decision and once for the office move. The two searches took 6.9 seconds and 9.6 seconds. Each reads only this organisation’s notes, and every hit comes back with a citation handle such as[B7]. - It reads the decision note in full (
quoxbrain_read, 1.5 seconds), so the answer rests on the whole record and not on a search snippet. - It answers, citing the note by its handle. Quox stores which notes the answer cited with the conversation, so anyone can see afterwards what the answer leaned on.
- It writes nothing. You asked it not to change notes, and it did not: no note was saved, edited or deleted, and no shell command ran.
The result
Section titled “The result”Quox answered both questions from the organisation’s records:
- The decision: “The decision is PostgreSQL 16, not MongoDB.”
- Where it is recorded: the note “Decision: Kestrel order system runs on PostgreSQL 16, not MongoDB”, cited as
[B7]and dated 6 Nov 2026. That is the exact titlequox brain readreturns for note2fe0e4447030a8def1d2eaad576a079439669760. - Why, as recorded: every order has to update stock and take payment in one transaction; and the ops team already runs Postgres backups and test-restores them every night.
- What was turned down, as recorded:
- MongoDB: its multi-document transactions have never been tested under order load.
- DynamoDB: it brings vendor lock-in, and finance would have no SQL.
- One related note it flagged for the budget: Kestrel reporting runs on BigQuery, loaded nightly from the order database, because reporting straight off the live PostgreSQL primary was rejected: one heavy dashboard query could slow checkout. Quox kept this separate from the database answer.
- The office move: “Nothing was recorded. I searched the knowledge brain for a decision on an office move and found no note on it. […] I won’t guess at an answer.”
- Sources: the notes it used, listed by handle and title at the end, and a closing line: “I saved and changed nothing.”
The proof engine then checked the brain’s own records after the turn. The decision note reads back with PostgreSQL 16 in its title, and with the same reasons and rejected options the answer gave. The stored citation record for the turn shows that note cited in the answer, and never marked contradicted. A brain search for the office move comes back flagged as insufficient, with no hit that mentions an office.
What that got you: before signing off the budget, the decision in the team’s own words, the reasons it rests on, what was ruled out and why, and the note to open if anyone asks where it came from. And a plain “nothing was recorded” on the question nobody had written down, so there is no invented answer to act on.
Do it yourself
Section titled “Do it yourself”Ask headlessly, then check the answer against the brain yourself:
quox --print "What did we decide about the database for the Kestrel order system, and why? Tell me which options we turned down, and cite the note it is recorded in. Don't save or change any notes."quox brain search "Kestrel order system database"quox brain read 2fe0e4447030a8def1d2eaad576a079439669760quox brain search "Kestrel office move" -o jsonquox brain citations --session <conversation id>quox brain read shows the note in full: the record the answer is checked against. A quox brain search that comes back with "insufficient": true is the brain itself saying it holds nothing on that topic. quox brain citations --session shows which notes a chat answer cited, so you can confirm it leaned on your records and not on its own earlier replies.
How it is checked
Section titled “How it is checked”The proof engine asked through chat, then checked the brain’s own records after the turn, not just Quox’s answer. Eight steps, in order:
- The decision: a brain search ran, the decision note read back holds “PostgreSQL 16”, and the answer says PostgreSQL 16;
- The source: the answer names the note by the id or exact title that
quox brain readreturns; - The first reason: the note records “one transaction”, and the answer gives it;
- The second reason: the note records the backups, and the answer gives them;
- The first rejected option: the note records MongoDB as turned down, and the answer names it;
- The second rejected option: the note records DynamoDB as turned down, and the answer names it;
- The honest “nothing”: a brain search for the office move is flagged insufficient by the brain itself, and the answer says no note was found;
- No hidden office decision: none of that search’s hits mentions an office, so there was nothing for the answer to lean on.
On top of the eight, seven guards had to stay clean: the turn’s stored citation record cites the decision note; it cites it in the answer itself, not just among the notes retrieved; it never marks that note contradicted; it never cites a memory of an earlier chat, so the answer cannot pass by quoting itself; no shell command ran; no note was saved, changed, deleted or restored; and the answer never put the order system on BigQuery or invented an office move. All 8 steps passed in order, and all 7 guards were clean.
Receipts
Section titled “Receipts”The run shown above is public at ev_mw4xqj7x_e4a9e4, recorded on 6 November 2026 in the scratch workspace. The receipt is the evidence, not this page.
The evidence bundle for this run is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role). Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw4xqj7x_e4a9e4.json. It passes only if the bundle is the copy we published and witnessed, unchanged.
The proof engine rates this Journey OBSERVED: it has passed on one UTC day, 6 November 2026. It becomes VERIFIED only after it passes again on a second day.
Quox-verified, not independently audited: the run was checked by Quox’s own proof engine against the running system, and the evidence id is published so you can recompute it. It is not a third-party audit.
What this journey can not establish
Section titled “What this journey can not establish”- That the decision was right, or still holds. Quox reports what was recorded. If the team changed its mind and nobody updated the note, the answer is faithfully out of date.
- That a decision recorded somewhere else does not exist. “Nothing was recorded” means nothing in this organisation’s brain. Quox does not search your email or chat history unless those are connected as sources.
- That the meaning of every sentence was checked against the note. The steps above check the decision, the source, the reasons and the rejected options against the note, and the citation record shows the note cited and not contradicted. Nothing here checks each sentence’s meaning against the note; that kind of check is off in this workspace.