ADR 0005 — Prove Argus on engineering work before generalising it

The forces at the time

The problem Argus addresses is not specific to engineering. Context evaporates everywhere: why a supplier was chosen, what a room was measured at, what the plan was before it changed. An assistant that observes state, retains records, and answers questions about them is a general-purpose tool, and that is the intended end state.

The risk in building for that end state directly is well documented and easy to walk into. A system built to handle anything tends to handle nothing convincingly, because there is no specific user whose specific failure would prove it wrong.

Infrastructure work is unusually demanding as a first domain: the state is machine-readable but scattered across incompatible sources, the decisions are consequential and easy to get wrong, the cost of a confident wrong answer is high, and the person asking is capable of noticing when the answer is nonsense.

What was chosen

Build and prove the three faculties — observation, memory, interaction — against infrastructure and engineering work first. Treat that domain as a test harness rather than as the boundary of the product.

Keep the faculties domain-agnostic in design. Observation reads sources , not switches . Memory stores records , not architecture decisions specifically . Nothing in the platform layer is permitted to learn what a VLAN is; that knowledge belongs in a module, which is the same rule the platform already follows.

A second, non-technical domain is the real test of whether that separation held. Until one exists, the generality is a claim rather than a demonstration, and this site says so.

What else was considered

Build the general assistant directly

Rejected. Without a specific demanding domain there is no failing case sharp enough to correct the design, and generality asserted early tends to become generality assumed forever.

Scope it permanently to engineering

Rejected. It would justify baking domain knowledge into the platform layer, which is exactly the coupling that makes a second domain impossible later.

Start with a low-stakes personal domain

Rejected as a starting point. Easier to build, but the failure modes are too forgiving to expose whether retrieval and attribution actually work.

What follows

Gained

Every faculty is validated against a domain where a wrong answer is obvious.
The platform/module boundary is enforced by a rule that can be checked, not by intent.
The first domain produces real records, which is the material the memory layer needs to be tested against at all.

Paid for

The assistant looks narrower than it is designed to be, and this site reads as engineering-specific as a result.
Generality remains unproven until a second domain exists. It is a design property, not a demonstrated one.
Domain-agnostic abstractions cost more to build than the specific version would have.