Argus, record why we chose MQTT over HTTP polling for the lighting nodes.
- Drafted ADR-0001 · proposed
- Context gathered from broker config and device topics
- Held for review — not accepted
Faculty III · Interaction
Voice
Documentation loses at a specific moment: hands busy, context fully loaded, and the cost of opening an editor higher than the perceived value of the record. If capture costs one sentence, the calculation changes.
Rule Argus drafts, it never asserts. Nothing it writes is authoritative until a person accepts it.
The moment of decision is the worst time to write anything down.
You are mid-problem, the context is entirely in working memory, and the decision feels self-evident — precisely because you can currently see all the reasons at once. Writing them out feels like transcribing the obvious. By the time it stops being obvious, the reasons are gone.
That gap, between when capture is cheap and when it feels worthwhile, is not a discipline problem. It is a friction problem, and friction is something you can actually engineer against.
What asking would look like
Every one of these is labelled with what it requires and how far along it is. None of them work today.
Argus, document this pinout: GPIO 18 data, 5V injected at both ends, 470Ω in line.
- Attached to the lighting build notes
- Flagged: the power injection decision has no record
- Suggested a follow-up record
Argus, which lighting zones are offline?
- Reads retained availability topics
- No polling — the broker already knows
- Reports last reported state and when
Argus, what changed before that deployment started failing?
- Correlates records and collected config over a window
- Returns candidates, ranked, with sources cited
- Answers with evidence, or says it does not know
Argus, why did we go with this supplier instead of the cheaper one?
- Same retrieval path, different subject
- Nothing about this question is engineering-specific
- Requires a record to have been kept at the time
Argus, the alcove is 84 by 31 inches — keep that with the workshop notes.
- A note is a record with a looser schema
- Retrieval does not care what the subject was
- The faculty generalises; the module is what differs
An engineering assistant, by proving ground only.
Look at the last two interactions above. Neither is about infrastructure, and neither needs a different mechanism — the same retrieval path answers "why this supplier" and "why this transport", because the faculty does not care what the subject was.
Infrastructure is where Argus is being built and tested because it is the hardest case: state scattered across incompatible sources, decisions expensive to get wrong, and an operator who will notice immediately when an answer is nonsense. Nothing in the platform layer is permitted to learn what a VLAN is — domain knowledge belongs in a module, which is the same rule Nexus already follows.
ADR 0005 — the scope decisionThree things it must not do
An assistant with access to your infrastructure and your reasoning is only useful if the limits are decided before the capability exists.
- 01
Never assert
Records drafted by Argus land as proposed, attributed to the assistant. Only a person moves one to accepted. An assistant that can quietly author authoritative history is worse than no assistant.
- 02
Never guess
Answers cite the source they came from, or say plainly that the information is not held. A confident wrong answer about infrastructure costs more than no answer, because it gets acted on.
- 03
Never act
The observation path is read-only and holds no method capable of changing state. That is a structural separation at the client level, not a policy — the same rule the printer integration already follows.
Text first. Voice is the obvious ending, not the starting point — it only earns its place once the text path is genuinely useful.
Back to Eyes