3. Related work

3. Related work

Design-oriented uses of ANT exist, and several neighbouring practices cover parts of what the framework does. This section sets out the nearest work in five areas and states the gap narrowly. It draws on Appendix A, parts 1.8 and 1.9, and on a targeted search of five fields made on 12 November 2026.

3.1 Design-oriented uses of ANT

Akrich's concepts of script and de-scription (1992) are the nearest thing in ANT's founding texts to a designer's concept. Hanseth and Monteiro (1997) showed that information-infrastructure standards inscribe behaviour at individual, organisational and inter-organisational levels; their paper is mainly diagnostic, but draws design implications. Braa and others (2007) turned that line of analysis into a "flexible standards" strategy for health information systems, and Braa, Monteiro and Sahay (2004) argued that interventions must be scaled through networks to last. Star and Ruhleder (1996) drew design lessons from a system its users liked but struggled to adopt as infrastructure. Binder and others (2011) treated design as gathering an assembly around a matter of concern.

The nearest ANT-based advice for system development is Underwood (2001). He recommends a "script audit" that records significant scripts and notes any that are dropped or drastically changed. That is a forerunner of the framework's drop and substitute loss modes, applied to requirements rather than to values. He argues against sign-offs, which the framework's gates require. Pouloudi and others (2004) used ANT to identify actors for stakeholder analysis. Alexander and Silvis (2014) proposed a graphical syntax for ANT, from which the framework's notation takes its freeze frames (Appendix E).

3.2 Socio-technical design and technology assessment

Socio-technical design methods such as Mumford's ETHICS define stages from diagnosis to implementation (Leitch and Warren 2010). Socio-technical systems engineering adds "sensitisation and awareness" and "constructive engagement" as activity types (Baxter and Sommerville 2011). Constructive technology assessment shifts assessment from predicting impacts to broadening design early (Schot and Rip 1997), and hybrid forums organise uncertain technical decisions with those they affect (Callon, Lascoumes and Barthe 2009). These approaches tell builders what to do, but at the level of programmes, infrastructures and deliberation. They define stages, not signed gates, and do not test a system's output against an independently computed answer.

3.3 Safety engineering

System-theoretic process analysis (STPA) examines unsafe control actions, authority and feedback in a control structure. Doshi and others (2026) apply STPA to the workflows of agents built on large language models (LLMs), derive requirements and specifications, and enforce them on data flows and tool sequences, with labels for confidentiality and trust. That is the closest single source to the framework: it has numbered specifications and a runtime confirmation step. Its labels carry confidentiality, not meaning, and its confirmation is a runtime approval, not a signed analysis, design or release gate. It does not use ANT. The framework hands write tools to a method such as STPA (Section 4.6) rather than replacing it.

3.4 Data quality, lineage and integration

Data-quality work checks accuracy, completeness and timeliness at the source. IP-MAP represents the stages an "information product" passes through, so quality can be assessed stage by stage (Shankaranarayanan, Wang and Ziad 2000). The Context Interchange project resolved semantic conflicts between sources and receivers, such as currency and scale factor (Goh and others 1999); that is close to the framework's re-base mode, in database integration rather than agents. Lineage and provenance record where a value came from. None of these asks whether a value's meaning survived each step for one decision, or whether an agent's answer matches a computed one.

3.5 Recent work on agents and tools

Fan and others (2026) measure "information fidelity" across sequential calls to Model Context Protocol (MCP) tools, as a total distortion score, and suggest re-grounding at intervals. She, Liang and Kang (2026) check, before execution, whether each tool-call parameter can be traced to the request or to earlier results. Both address parts of the agent side. Neither names loss modes, ties fidelity to one decision, or tests against a computed answer.

3.6 Hazard analysis, assurance and stage gates

Three further practices are close neighbours, although the search did not cover them. HAZOP applies guide words such as "no", "more", "less" and "other than" to each flow in a process design to find deviations (Kletz 1999). Failure modes and effects analysis (FMEA) lists the ways each component can fail and what follows. Both name types of failure for each flow, which is close to the framework's loss modes, but they apply them to physical or functional quantities, not to the meaning a value carries to a decision.

Assurance cases argue that a system meets a claim, with evidence for each step of the argument, often in the Goal Structuring Notation (Kelly and Weaver 2004). Stage-gate processes require a signed review between phases (Cooper 1990). Both are close to the framework's signed gates.

Work on the test-oracle problem studies how to know the right output for a test (Barr and others 2015); the framework's oracle is one answer to it, computed from business rules. Provenance standards such as W3C PROV record where a value came from (W3C 2013). Security writing on MCP describes tool poisoning, in which a tool's description carries hidden instructions; the framework treats such text as a rival meaning.

3.7 The gap, stated narrowly

Each part of the framework has precedents. What none of the work above combines, for one decision, is four things:

1. named records;
2. signed gates;
3. a test against an independently computed answer;
4. hop-by-hop tracking of named loss modes through software agents.

That combination is the contribution. Hazard analysis names failure types for each flow, and assurance cases and stage gates require signed evidence; none of them is tied to the meaning of one value at one decision, tested against a computed answer.

The search behind this section opened 15 sources: 7 were read in full and 8 from abstracts or record pages. Some cited works, such as Goh and others (1999) and Shankaranarayanan and others (2000), were seen only in listings, and the full texts of Roque and others (2003) and Brender (1999) could not be obtained. All of these are marked † in the references. The practices in Section 3.6 were not searched at all. It was not a systematic review, and requirements engineering was covered least. Work on LLM agents is appearing quickly, so any review will soon be out of date. Section 7.3 states the claim this supports.