Engagement inputs
What the work may use
- Audit work program
- Criteria and methodology
- Permitted evidence
- Engagement context
AI-Augmented Engagement Operating System
Examine more of the evidence, without losing the audit trail.
AEOS is a file-based operating system for auditors working with AI. It turns an audit work program (AWP) into a controlled route for evidence, testing, workpapers and reporting drafts. It is independently developed, and actively used and tested in audit fieldwork.
Where AEOS works
Support across fieldwork: evidence review, testing, reporting.
AEOS picks up after the audit work program is authorized and stays with the engagement until the reporting draft. Three kinds of work happen in that span, and it supports each of them differently.
-
Evidence review
Sources are registered before anything relies on them, under a declared source mode: either an exact named file set, or approved roots with bounded link traversal. Provenance is recorded, and where an expected record was never provided, that becomes a named absence on the workpaper rather than a quiet omission. An optional evidence wiki gives the registered set a navigation layer, which is not itself evidence.
-
Testing
Test of design first, in week one. Test of operating effectiveness after, in week two, and only once the auditor has approved the design conclusion, the population, the completeness basis and the sampling method. Execution records are written to a separate working area and stop at an auditor checkpoint before any workpaper is updated.
-
Reporting
Per-procedure progress updates are drafted from reviewed workpapers at the end of each week, with interim observations kept explicitly non-final. They are review-only drafts. AEOS never transmits one, and only an authorized person can send anything.
There is also an engagement buddy. When the work gets away from you, one read-only route ranks what is open right now into NOW, NEXT, WAITING and BLOCKED, with a source locator against each item. It changes nothing and decides nothing.
The point is not a faster first draft. It is getting through more of the evidence, at more depth, and still being able to show a reviewer how every statement got there.
What AEOS is
One governed workspace for the engagement, not a folder of prompts.
AEOS is a second reader for the engagement, built as a workspace rather than a chat window. It brings the engagement context, the AWP, criteria, evidence, workpapers, workflow instructions and review decisions into one place. It starts after the work program is authorized. From there it covers fieldwork preparation, meetings, evidence handling, design and implementation assessment, operating-effectiveness testing where applicable, review, progress updates and reporting drafts.
Engagement inputs flow through the governed operating core into draft audit work, while human decisions retain reliance and communication authority.
Governed operating core
How the work is controlled
- Workspace and source register
- Task context
- Governed workflow
- Template and operating guide
Draft audit work
What AEOS prepares
- Design and operating-effectiveness workpapers
- Meeting and evidence records
- Progress updates
- Reporting drafts
Human decisions
What remains with the auditor
- Evidence reliance
- Sampling and exceptions
- Conclusions and sign-off
- External communication
What separates this from a collection of audit prompts is where the controls live. Evidence state, workflow authority and approval are built into the product rather than added as reminders inside a prompt. The professional concepts draw on public audit guidance; the workflow stages, labels and workspace structure are AEOS design choices, not an IIA-prescribed methodology.
A walkthrough
One procedure, four sources, and one attribute with nothing behind it.
Procedure AI-04 in a fictional GenAI change-governance engagement: assess whether production changes to a generative AI service are evaluated, authorized, deployed and monitored through change management. The auditor scoped it to the first half of 2026 and listed the evidence the assessment would need. A change register, deployment records, a model registry, evaluation records and authorization records. Five kinds of record. Watch what happens to the fifth.
The four captures below are literal screenshots of the demonstration workspace open in Obsidian and Visual Studio Code. The workspace and every record in it are synthetic and were built for publication. Select any image to open it at full size.
01
Obsidian
The engagement is a folder, not a chat history.
02
Visual Studio Code
The work program stays the authority.
03
Visual Studio Code
The task is bounded before the model sees anything.
04
Obsidian
Every attribute is traced back to a file.
What happened
The fifth kind of evidence never arrived. The attribute that needed it, evaluation approved before deployment, points at E-004. E-004 was not among the four files the auditor authorized, and no approval record was provided. So the draft records exactly that, against that attribute: source gap.
That is the part worth having. Not a summary that quietly drops an attribute it had nothing for, and not an inference that the evaluation probably happened. A named attribute, pointing at a missing record, sitting on the workpaper where a reviewer will see it.
Nothing else moved either. Testing: not performed. Conclusion: blank, auditor-owned. The version comparison is prepared but left unconcluded, because finding an identifier in two sources is not the same as deciding they agree. Item-level testing waits until the auditor approves the population, sample, attributes and evidence route.
The engagement lifecycle
Six stages, each with an output and a decision the auditor keeps.
AEOS begins after the work program has been reviewed and authorized under the internal audit function's methodology. It does not require one fixed work-program layout: a wide spreadsheet and a narrative document can both enter through governed interpretation.
| Stage | What it produces | Auditor decision |
|---|---|---|
| 1. Set up the engagement | A registered engagement context, applicable criteria, AWP, source set, and AI read and write boundaries. | Resolve missing identifiers, inaccessible criteria and conflicting source versions. |
| 2. Prepare fieldwork | Interpreted procedures, workpaper scaffolds, walkthrough topics, evidence-request candidates, source-linked meeting and evidence records, and a fieldwork plan. | Review that interpretation before execution. |
| 3. Assess design and implementation | An assessment of whether the control exists, has been implemented, and is capable of mitigating the identified risk if it operates as intended. | Decide whether the work performed supports the design conclusion. |
| 4. Assess operating effectiveness | Item-level testing, where applicable, of whether a design-confirmed control operated consistently and correctly over the relevant period. | Approve the population, completeness basis, sampling method, selected items, attributes and evidence approach before testing. |
| 5. Review and reconcile | Separate read-only review that challenges source support, missing evidence, internal consistency, and conclusions exceeding the work performed. | Approve corrections, which are verified before merge. |
| 6. Prepare reporting | Progress and reporting drafts built from reviewed workpapers and documented exceptions. | Approve and send any external communication. |
A walkthrough can support the design-and-implementation assessment, but it does not establish sustained operation. These are AEOS product stages: public professional guidance provides context for work programs, design evaluation, testing, documentation and conclusions, but does not prescribe this six-stage structure.
What keeps the work reviewable
Five distinctions stay visible from source to reporting.
Internal audit work is a chain of dependent judgments. A workpaper depends on a defined procedure. A test result depends on retained and reviewed evidence. A conclusion depends on the attributes tested and the exceptions identified.
- Authorized source, as distinct from agent inference.
- Expected evidence, as distinct from evidence obtained.
- Design-and-implementation assessment, as distinct from operating-effectiveness testing.
- Draft result, as distinct from auditor-approved conclusion.
- Internal draft, as distinct from authorized communication.
The states a draft can carry
-
Source gap
An expected record was not provided. It is named against the attribute that needed it, not dropped from the analysis.
-
Not established
The authorized sources do not answer the question. The question stays open and goes to the auditor.
-
Incomplete record
The record exists, but a field the criterion depends on is absent from it.
-
Prepared; not concluded
A comparison against the criterion is ready. The judgement it supports has not been made.
-
Available; review pending
The source is registered and readable. Its reliability has not been reviewed yet.
Human authorization sits at the four points where work changes authority: an AWP procedure becomes a draft workpaper, received material becomes relied-upon evidence, a test result becomes an audit assessment, and a reviewed conclusion becomes external communication.
- AWP intake and workpaper setup
- Walkthroughs, meetings and evidence requests
- Design-and-implementation assessment and operating-effectiveness testing
- Separate review, correction and merge routes
- Progress, reporting and lessons-review drafts
- Scope, criteria and source authorization
- Population, sampling and exception decisions
- Evidence sufficiency and reliance
- Conclusions, sign-off and reporting judgment
- Every external communication
- Discovery and creation of the audit work program
- Autonomous approval, sign-off or transmission
- Enterprise audit scheduling or budget ownership
- Use of restricted evidence on an unapproved route
- Final engagement conclusions or observation closure on the auditor's behalf
What you get and how you set it up
A workspace you can open, read and check.
AEOS runs in Visual Studio Code and Obsidian. There is no separate backend and no service to sign up for. Everything you get is a file you can open, so the system can be inspected the same way the audit work can.
| What you get | What it is | What you do with it |
|---|---|---|
| Engagement workspace | A folder structure for context, plans, evidence references, workpapers, reviews and reporting drafts. | Open it once per engagement. Everything else runs inside it. |
| Task contexts | Definitions that set the professional perspective and the evidence, file and authority boundaries for a task. | Pick the one that matches the work before you start a task. |
| Governed workflows | Named routes defining required inputs, stage order, stop conditions and where output goes. | Invoke one per task. It runs against the sources you authorized. |
| Templates and guides | Readable output structures for workpapers and records, plus operator instructions. | Read the guide, review what the template produced. |
| Evidence and review controls | Source identity, provenance, derivative relationships, gaps, contradictions and draft state. | Nothing to configure. They keep draft output from becoming silent authority. |
| Deterministic checks | Optional Python checks for structure, paths, required fields and packaging. | Run them when you want a mechanical check. They never decide evidence or conclusions. |
Setting it up
-
01
Open the workspace
Open the AEOS folder as a Visual Studio Code workspace and as an Obsidian vault. Both point at the same files.
-
02
Confirm discovery
Check that Visual Studio Code lists the AEOS task contexts and workflows, so the governed routes are selectable in Copilot Chat.
-
03
Choose the provider route
Select an approved route before selecting a model: a Copilot-hosted model inside an approved service boundary, or local Ollama through the supported provider extension.
-
04
Run a governed test
Run one supported route against a sample engagement and confirm it produces the expected draft in the expected location.
-
05
Verify the runtime
Confirm which task context and model actually ran. Static documentation is not proof of the runtime route.
What invoking a governed route looks like
/tod-analysis-to-workpaper
AWP AWP04 sub-process rd_ai_change_control
Source mode EXACT_FILES
Approved AWP04, E-001, E-002, E-003, E-004
Do not select a sample · approve reliance
update the workpaper · conclude
Stop at auditor checkpoint
Requirements
What a team needs to run AEOS.
The workspace remains readable and portable. Native originals stay linked and authoritative, while information used by AEOS agents and workflows is provided in reviewed Markdown working copies.
Working environment
- Visual Studio Code
- GitHub Copilot Chat with authenticated access
- Obsidian and the AEOS workspace
Engagement inputs
- An audit work program
- Defined criteria and methodology
- A permitted source set and file boundaries
Markdown working copies
- Reviewed Markdown required for information used by AEOS agents and workflows
- Native originals retained and linked as authoritative evidence
- User-supplied conversion or the separate file-converter product
Approved provider route
- Copilot-hosted models within an approved service boundary
- Local Ollama or Ollama Cloud through the supported provider extension
- Provider, route and use case approved for the evidence involved
LLM operating contract Choose the provider route, then the model. View contract
AEOS supports defined provider routes rather than generic model independence. The auditor chooses an approved route, then selects a model with the context, source-mapping, structured-output and file-tool capability required for the task.
- Data boundary
- Restricted evidence stays off remote services unless the provider and use case are approved.
- Runtime record
- Record the agent, model ID, provider boundary, source set and output location for each governed task.
- Output discipline
- Cite sources, show gaps and contradictions, leave unsupported fields blank and route every output to the auditor.
- Authority
- The model may interpret, compare, test and draft. It cannot approve samples, exceptions, conclusions, sign-off or communication.
- ZDR boundary
- Zero Data Retention can reduce retention exposure. It is not the same as local processing, tenant isolation or private tenancy.
Common questions
The short answers.
- Where does AEOS start?
- After the audit work program (AWP) has been reviewed and authorized under the internal audit function's methodology. Missing planning decisions remain open for the auditor.
- What do I actually install?
- Visual Studio Code, Obsidian, GitHub Copilot Chat and the AEOS workspace folder. There is no AEOS server, backend or hosted service.
- Does my audit data leave my machine?
- That depends on the provider route you approve. A local model keeps processing on your own hardware. A Copilot-hosted or Ollama Cloud route sends content to that provider, so restricted evidence needs the provider and use case approved first.
- Does AEOS replace the auditor?
- No. It supports preparation, evidence analysis, testing and drafting. The auditor owns professional judgment and approval.
- Do all source documents need to be Markdown?
- Native originals do not. AEOS retains and links them as the authoritative evidence. However, information used by AEOS agents and workflows must be available in reviewed Markdown. The user must provide that Markdown working copy, either by converting the information themselves or by using the separate file-converter product.
- Does AEOS require one model?
- No. It requires an approved provider route and a model capable of the selected workflow.
- Can AEOS send audit communication?
- No. It may prepare a draft. Only an authorized person can send or publish it.
AEOS