The Archieve of AUDINTRA

With Audintra, I’m interested in a problem that can remain even when an organisation has documented its work carefully: how does someone know whether those documents still describe what is happening?

A requirement may have an owner and a supporting procedure, yet that tells us little about whether the procedure is being followed or whether the available evidence still applies. I wanted to explore how software could help people follow those relationships closely enough to recognise where attention is needed.

That is the direction I am developing Audintra around, as an integrated management system connecting formal requirements with the work that fulfils them. The ambition is substantial, but the design question becomes quite concrete when I consider what happens to one requirement over time.

Suppose a requirement changes after a control has been assessed. The previous assessment remains a record of what was examined, but its relevance to the revised requirement now needs consideration. I would want the system to make that relationship visible so the responsible person could decide what needs reviewing. Automatically carrying forward a reassuring status could conceal the very uncertainty the system should help expose.

It affects how I think about evidence, too. Attaching a file is straightforward; understanding what it supports requires more context. A document might relate to a particular period or only one part of an operation. If that scope disappears when the file is reused elsewhere, the system could make the organisation appear more certain than the evidence warrants.

For Audintra, I want those distinctions to influence the structure of the product from the beginning. The interface depends on them, because a status becomes useful when someone can understand its basis and recognise what action, if any, it calls for.

Responsibility needs similar care. Naming an owner is one step, but the work may pass between several people before it is complete. I’m interested in making those handovers understandable, particularly when a finding requires corrective work and someone else must later assess whether that work addressed the issue. Completing an action and establishing that it was effective are different judgments, and the product needs room for both.

This is also how I decide whether a broader feature belongs in the system. I want to know which connection it strengthens and what decision becomes easier because it exists. If it introduces another record to maintain without helping someone understand or advance the work, its place needs questioning.

The challenge is to make that depth manageable. Someone carrying out an assigned action should be able to see what is expected and provide the relevant evidence without navigating the organisation’s entire management structure. The wider context should remain accessible to the people who need to examine it.

Audintra is still in development, so these are design commitments I need to test through the product. I would want to see whether someone can follow a requirement through to the evidence supporting it, recognise an unresolved gap, and understand who needs to act next.

What draws me to this project is the work of making a complicated organisation understandable without pretending it is simple. I want to build software that preserves the distinctions people need for sound judgment while removing the effort of repeatedly reconstructing how everything fits together.