Engagement inputs
What the work may use
- Available EWP / AWP
- Criteria and methodology
- Permitted source boundary
- Engagement context
AI-Augmented Engagement Operating System
A structured workspace for fieldwork planning and execution.
AEOS is the AI-Augmented Engagement Operating System. It brings the available engagement work program, context, evidence, meetings, testing, workpapers, review, progress reporting and reporting drafts into one file-based working environment.
What AEOS supports
Supervised work from EWP intake through review and reporting support.
AEOS begins with an available Engagement Work Program (EWP), also referred to as an Audit Work Program (AWP). Its current focus is fieldwork planning and execution. It does not yet create the EWP or its test procedures; that capability is under development for a future release.
-
Engagement setup
AEOS prepares the engagement workspace, checks readiness for substantive work, and establishes the context, permitted source boundary, criteria and methodology.
-
EWP intake and fieldwork planning
AEOS works from the available EWP, prepares separate Draft workpapers, and plans procedures, evidence, information requests, meetings, dependencies and open auditor decisions.
-
Meetings and evidence
It prepares meeting material, records factual minutes, registers evidence, and keeps links between sources, procedures, tests and workpapers. Missing or contradictory information remains visible.
-
Testing and documentation
For Audit engagements, AEOS documents Test of Design activities and prepares Test of Effectiveness testing after the auditor confirms the population, sample, attributes and evidence approach.
-
Review and progress
Draft workpapers move through auditor checkpoints, separate quality review, controlled correction, verification and merging. AEOS also prepares progress updates from the reviewed work.
-
Reporting and continuity
AEOS supports Draft observation, conclusion and reporting wording, while engagement-local memory keeps next actions, milestone lessons and field-test feedback available to the work.
For Audit engagements, the route can include Test of Design, Test of Effectiveness, quality review, reporting drafts and closure. Advisory engagements follow the available EWP without automatically adopting Audit-specific testing stages or reporting terminology.
How the parts operate as one system
The components work together inside one engagement workspace.
AEOS combines a structured workspace with agents, skills, prompts, templates, knowledge, memory, guardrails and human checkpoints. The workspace supplies the context, the selected agent provides the professional role, the skill controls the task, the template controls the output structure, and the auditor decides whether the work may move forward.
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 selected agent
- Skill, prompt and template
- Knowledge and memory
- Guardrails and human checkpoints
Draft audit work
What AEOS prepares
- Fieldwork plans and evidence records
- Testing and workpaper content
- Progress updates
- Reporting drafts
Human decisions
What remains with the auditor
- Scope and testing basis
- Evidence reliance and exceptions
- Conclusions and sign-off
- External communication
The value comes from the connection between these parts. Sources, procedures, work performed, testing, gaps, contradictions, reviews and conclusions remain linked, while professional authority stays with the auditor.
What AEOS looks like in practice
A procedure stays connected to its sources, gaps and auditor decisions.
A typical Audit route starts with one procedure from the available EWP. AEOS interprets that procedure inside the engagement context, prepares the fieldwork plan and Draft workpaper, and keeps the expected evidence visible beside the material that was actually obtained.
-
Start from the available procedure
The procedure, objective, scope, period and expected evidence remain visible. AEOS does not replace them with a generic prompt or create a new work program.
-
Bound the task
The auditor selects the relevant agent and skill, names the permitted sources and output, and sets the professional checkpoint before the model runs.
-
Register the evidence
Sources are linked to the procedure and workpaper attributes. Missing support, contradictions, reliability questions and unresolved reconciliation remain explicit.
-
Keep the result in Draft
Population and sampling fields stay blank until the auditor confirms the testing basis. AEOS may prepare analysis and Draft wording; the auditor evaluates exceptions and owns the conclusion.
Fictional public example
The public example follows a procedure assessing whether changes to a generative AI service are evaluated, authorized, deployed and monitored through change management. The records and engagement are synthetic.
Where support is missing or sources do not reconcile, AEOS records the condition against the relevant attribute and routes it for follow-up. It does not turn the issue into a tested exception, an operating-effectiveness result or a conclusion.
The engagement lifecycle
Five stages, each with support from AEOS and a decision the auditor keeps.
AEOS begins with the available EWP or AWP. It does not require one fixed layout: a spreadsheet, structured document or narrative plan can enter through governed interpretation when the source authority and engagement scope are clear.
| Stage | AEOS support | Auditor decision |
|---|---|---|
| 1. Prepare | Creates Draft workpapers, proposed evidence requirements, meeting topics and a fieldwork plan. | Confirms the procedure interpretation, scope and plan. |
| 2. Gather evidence | Registers documents and meeting records, links them to the procedure, and identifies missing or contradictory information. | Decides what may be relied upon and what follow-up is required. |
| 3. Test | Documents Test of Design work and, where applicable, performs item-level Test of Effectiveness testing after the testing basis is confirmed. | Confirms the population, sample, attributes and evidence approach, evaluates exceptions, and owns the assessment. |
| 4. Review | Runs separate quality review, records controlled corrections and verifies the revised workpaper. | Approves corrections and decides whether the work is sufficient. |
| 5. Report | Prepares progress updates and Draft observation, conclusion or reporting wording. | Owns the final conclusion, rating, sign-off and communication. |
A walkthrough can support the design-and-implementation assessment, but it does not establish sustained operation. Advisory engagements follow the available EWP without automatically adopting Test of Design, Test of Effectiveness or Audit reporting stages.
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.
- Registered 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 registered 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 points where work changes authority: an available EWP or 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.
- EWP or AWP intake and Draft 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 the permitted source boundary
- Population, sampling and exception decisions
- Evidence sufficiency and reliance
- Conclusions, sign-off and reporting judgment
- Every external communication
- Creating the EWP and its test procedures (future release)
- Unsupervised end-to-end engagement work
- Autonomous approval, sign-off or transmission
- Enterprise audit scheduling or budget ownership
- Final engagement conclusions or observation closure on the auditor's behalf
Technology without lock-in
Readable files, replaceable components, no required backend.
The current setup uses Markdown as the durable working format, Obsidian for engagement navigation, and Visual Studio Code with GitHub Copilot Chat as the main AI harness. AEOS does not require a separate application backend, database, Python environment or Git repository for its default core.
| 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. |
| Agents and skills | Reusable roles and task methods that define the professional perspective, required inputs and stop conditions. | Select the role and skill that match the fieldwork task. |
| Prompts and templates | Structured task instructions and output formats for plans, registers, workpapers, reviews and reporting drafts. | Use the relevant route and review the Draft it creates. |
| Knowledge and memory | Engagement context, decisions, evidence links, open gaps, working facts and reusable definitions. | Keep the engagement state current so later tasks start from the same record. |
| Guardrails and review controls | Source identity, provenance, working-state labels, gaps, contradictions, separate quality review and human checkpoints. | Confirm reliance, corrections and conclusions before the work moves forward. |
| Deterministic checks | Bounded checks for structure, paths, required fields and packaging. | Run the configured checks. They never decide evidence or conclusions. |
| Optional extensions | Python for repeatable processing and Git for background versioning and recovery. | Add them when the engagement benefits from automation or file history. Neither is required for the AEOS core. |
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 agents and skills so the relevant task route is selectable in Copilot Chat.
-
03
Choose the provider route
Select an approved route before selecting a model. Copilot-hosted models use an approved service boundary. Local Ollama and Ollama Cloud require Ollama installed and running, at least one local or cloud model available, and the official
Ollama.ollamaprovider extension. Ollama Cloud also requires Ollama sign-in. -
04
Run a staged task
Run one supported task against a sample engagement and stop at its auditor checkpoint. Confirm that the Draft appears in the expected location.
-
05
Verify the runtime
Confirm the agent, model, provider boundary, permitted source set and output location that actually ran. Static documentation is not proof of the route.
Requirements
What a team needs to run AEOS.
The workspace remains readable and portable. Native originals stay linked and authoritative. AEOS uses reviewed Markdown for its engagement context and working artifacts, while source documents can remain in their original formats.
Working environment
- Visual Studio Code 1.127 or newer
- GitHub Copilot Chat with authenticated access
- Obsidian and the AEOS workspace
- For local Ollama or Ollama Cloud: Ollama installed and running, at least one local or cloud model available, and the official
Ollama.ollamaprovider extension - Ollama Cloud also requires Ollama sign-in
Engagement inputs
- An available EWP or AWP
- Defined criteria and methodology
- A permitted source set and file boundaries
Markdown working copies
- Reviewed Markdown for engagement context, registers, plans, workpapers and review records
- Native originals retained and linked as authoritative evidence
- Reviewed derivatives added when they make source content easier to use
Approved provider route
- Copilot-hosted models within an approved service boundary
- Local Ollama and Ollama Cloud require Ollama installed and running, at least one local or cloud model available, and the official
Ollama.ollamaprovider extension - Ollama Cloud also requires Ollama sign-in
- Provider, route and use case approved for the evidence involved
Python and Git
- Python for repeatable processing or deterministic checks
- Git for background versioning and recovery
- Neither is required for the default AEOS core
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?
- With the available Engagement Work Program (EWP), also referred to as the Audit Work Program (AWP). Missing planning decisions stay open for the auditor.
- What do I actually install?
- Visual Studio Code 1.127 or newer, Obsidian, GitHub Copilot Chat and the AEOS workspace folder. Local Ollama and Ollama Cloud require Ollama installed and running, at least one local or cloud model available, and the official
Ollama.ollamaprovider extension. Ollama Cloud also requires Ollama sign-in. 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?
- No. Native originals remain linked as the authoritative evidence. AEOS uses Markdown for engagement context and working artifacts, and a reviewed derivative can be added when it makes a source easier to use.
- Does AEOS require one model?
- No. It requires an approved provider route and a model capable of the selected workflow.
- Does AEOS require Python or Git?
- No. Python can support repeatable processing, and Git can provide background versioning and recovery. Both are optional extensions.
- Can AEOS create the EWP?
- Not in the current release. EWP creation, including its test procedures, is a future capability under development.
- Can AEOS send audit communication?
- No. It may prepare a draft. Only an authorized person can send or publish it.
AEOS