From Audit Requirements to Computable Software Architecture: A Rule-Engine and Evidence-Indexing Method for Trusted Digital Infrastructure
This paper proposes a rule-engine and evidence-indexing methodology that bridges the semantic gap between audit requirements and software architecture by creating a classification model, mapping matrix, and verification algorithm to embed executable controls early in the design phase, thereby reducing remediation costs and enabling audit-ready digital infrastructure.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
Imagine you are building a massive, high-security bank vault. In the old way of doing things, you would first build the whole vault, put in the doors and cameras, and then, after it was finished, hire an inspector to say, "Oh, by the way, we need a second lock on the back door, and the cameras need to be connected to a different server." This leads to a lot of tearing down walls, rewiring, and expensive fixes.
This paper proposes a different way: building the security rules into the blueprints from day one.
Here is a simple breakdown of how the authors, Jinyuan Li, Ruijie Ma, and Yicheng Gu, suggest doing this for digital systems (like those used for managing digital assets).
1. The Core Problem: The "Translator" Gap
The authors point out that there is a language barrier.
- Auditors speak in rules like "We need proof that only the manager approved this transaction."
- Software Architects speak in code like "We need a database table and an API endpoint."
Usually, these two groups don't talk until the software is already built. The result is that security and compliance become "patches" added later, which are messy and expensive.
2. The Solution: A "Rule Engine" and "Evidence Index"
The authors created a method to translate the auditor's rules directly into the software's DNA before a single line of code is written. They use three main tools:
A. The "Translation Matrix" (The Recipe Book)
Think of this as a giant recipe book that turns vague rules into specific ingredients.
- The Rule: "We need to know who changed this data."
- The Translation: The system automatically knows it needs to create a "Version Lock," save a "Change Log," and generate a "Digital Fingerprint" (hash) of the data.
- The Result: Instead of a human guessing how to code this, the system knows exactly which "functional modules" (like a login service or a logging service) need to be turned on.
B. The "Rule Engine" (The Bouncer)
Once the rules are translated, they are loaded into a "Rule Engine." Imagine this as a bouncer at a club who checks a list of rules before letting anyone in.
- If you try to approve a transaction without a second person's signature, the bouncer (the software) stops it immediately.
- If you try to access a file you aren't allowed to, the bouncer blocks you.
- This happens automatically as part of the normal flow, not as an afterthought.
C. The "Evidence Index" (The Digital Filing Cabinet)
In the past, proving you followed the rules meant digging through messy paper trails or scattered computer logs.
- The authors propose a system where every action automatically generates a "receipt" (evidence).
- These receipts are stamped with a unique ID, a timestamp, and a digital signature.
- They are filed instantly into a special "Evidence Repository."
- The Analogy: It's like a smart filing cabinet that, the moment you sign a document, automatically takes a photo of it, stamps it with the date, and puts it in a locked drawer that only the auditor can open. You don't have to go find the paper later; it's already there, organized and ready.
3. How They Tested It: The Digital Asset Platform
The team tested this method on a "Digital Asset Management Platform" (a system for managing things like digital money or tokens). They compared two scenarios:
- Scenario A (The Old Way): Build the system first, then try to add the security rules later.
- Scenario B (The New Way): Build the security rules into the design from the start.
The Results:
- Fewer Fixes: The "Old Way" required 24 changes to the system's interfaces (like changing the shape of a door). The "New Way" only needed 7.
- Less Rewriting: The "Old Way" required patching 16 data structures (like rewiring the plumbing). The "New Way" only needed 3.
- Faster Testing: Testing the "New Way" took 58 hours of work; the "Old Way" took 143 hours.
- Better Proof: The "New Way" had 95% of the required evidence ready automatically, compared to only 70% for the "Old Way."
4. The Bottom Line
The paper argues that by treating audit requirements as computable instructions (like code) rather than just text documents, you can build systems that are "audit-ready" by default.
Instead of building a house and then realizing you forgot the fire escape, you draw the fire escape into the blueprint. When the house is built, the fire escape is already there, perfectly integrated, and ready to be inspected. This saves money, reduces stress, and makes the digital infrastructure much more trustworthy.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.