Governance & Compliance Focus
Disclose
An APP 1.7 assessment tool for Australian government agencies — built by mapping the whole problem first, not just the interface.
2
Governance Layers Defined
4
User Journeys Designed
9
Stakeholders Mapped
3
Outputs from One Assessment
Project Details
Client
Governance & Compliance (Demonstration for portfolio)
Duration
A couple of hours over a 2 day sprint (research, design, and three build iterations)
Skillset
Service Design, Business Process Analysis, User Journey Mapping, Structured Reasoning, Regulatory Research, Prototyping
Tools & Stakeholders
Tools
Claude (Sonnet 5) — regulatory research, stakeholder mapping, structured reasoning, prompt design
Claude Fable 5 — prototype build and iteration
Base44 — comparative rapid prototype
GitHub — version control
Netlify — deployment
Public sources: Digital Transformation Agency (DTA), OVIC, NSW Digital, Treasury Board of Canada Secretariat
Key Stakeholders (Hypothetical/Contextual)
-
Business/System Owners
-
AI Governance Specialists
-
Legal Counsel
-
Executive/Accountable Officers
-
Citizens affected by automated decisions
-
Technical Validators
-
DTA and equivalent state bodies
Case study details
From December 2026, Australian Government agencies must tell people when AI is used to help make decisions about them — that's what APP 1.7 requires. Separately, 94 agencies already had to build their own AI register by June 2026. Each one works alone: no shared system, no shared format, everything emailed to the DTA every six months.
Before building anything, I wanted to understand who's actually affected and what they each need. I researched the real rules — from the DTA, OVIC, NSW, and Canada's equivalent system — and mapped the problem before touching a tool.
This is a human-centred design project first, and an AI project second.
The regulation set the constraints. Service design method — stakeholder mapping, journey mapping, process analysis — is what actually shaped the tool.
The goal was never a finished system. It was to show that a compliance
process can be designed around the people who use it, not just the
regulation it's satisfying.
Photo by Ajaykumar Kannan on Unsplash
Here’s how the journey unfolded:
1. Research and stakeholder mapping
I researched the actual regulatory landscape rather than assuming it: DTA's Standard for Accountability (the real register field structure), the December 2025 policy overhaul, OVIC's Victorian guidance (and the jurisdictional gap between Commonwealth and state requirements), NSW's Excel-based AI Assessment Framework, and Canada's Algorithmic Impact Assessment — the closest global precedent, open-sourced, feeding a live public register.
From this, I mapped nine stakeholders — from the business owner screening a new system through to the citizen who eventually receives an automated decision — and four user journeys showing how each stakeholder actually moves through the process. This became a visual ecosystem map, built before any prototype work started, so the tool that followed was designed around real needs rather than assumed ones.
2. Stakeholder mapping — nine people, nine different needs
This exercise surfaced something important: APP 1.7 isn’t a single‑team compliance task. It’s a whole‑of‑system workflow involving nine different roles, each with a different responsibility, constraint, and definition of “done.”.
Why this mattered for the prototype
The map made one thing obvious: no single agency, and definitely no single 2-days prototype, can solve this alone. Each role touches a different part of the process — screening, assessment, legal review, technical validation, register integration, executive oversight, and ultimately the citizen who receives the decision. The prototype was designed to sit in the middle of that ecosystem, structuring the questions and making gaps visible, not replacing any of those roles.
What the mapping revealed
-
The work crosses legal, technical, and citizen-facing teams — it's not one team's job
-
Some roles — legal review, technical validation — can't be automated away
-
"Documented" and "Proven in Practice" only make sense once you see how many different people each one actually depends on
-
No single team should design this alone — it needs input from the people who'd actually use it
3. User Journeys — What Actually Happens, Step by Step
Mapping the stakeholders answered, "who's involved". This answers "what do they actually do," in order.
A business owner checking if a new system needs to be disclosed
Describes the system in plain language → answers three yes/no questions → finds out immediately if it's in scope → if yes, it's handed to the AI Governance Specialist
An AI Governance Specialist completing the assessment
For a genuinely new type of decision, legal counsel first checks whether the agency is even allowed to automate it — that's a one-time question, not repeated for every similar case afterward. The specialist then fills in the full assessment → it's saved as a draft → for lower-risk cases, the specialist can self-certify; for medium or higher-risk cases, both a technical reviewer and legal counsel have to sign off before anything is finalized → three documents are generated automatically: a register entry, a citizen notice, and an executive summary.
A citizen who's affected by an automated decision
Receives a decision from a government agency → reads a plain-language explanation of how it was made → can ask for the specific reasoning behind their own case → can request a formal review if they're not satisfied.
An executive tracking progress before the deadline
Opens a dashboard → sees how many systems are covered and how many aren't →sees which ones are properly proven, not just documented → flags gaps to the right person.
Different people, completely different experiences of the same regulation — which is exactly why one generic form was never going to work.
Why this mattered for the prototype
The map made one thing obvious: no single agency, and definitely no single 2-day prototype, can solve this alone. Each role touches a different part of the process — screening, assessment, legal review, technical validation, register integration, executive oversight, and ultimately the citizen who receives the decision. The prototype was designed to sit in the middle of that ecosystem, structuring the questions and making gaps visible, not replacing any of those roles.
What the mapping revealed
The compliance workflow crosses legal, technical, operational, and citizen‑facing domains. Some roles (technical validators, legal reviewers) are capability bottlenecks — you can’t automate them away. The “Documented vs. Proven in Practice” split only makes sense when you see how many people contribute to each layer.
Any real solution would benefit from co‑design across agencies and regulators, not a single team inventing a process in isolation.
4. Ecosystem View — Where Everything Connects (and Where It Doesn’t Yet)
The missing technical roles
These roles sit alongside compliance and legal review, not inside them:
-
AI Governance Specialist
Translates system behaviour into defensible, legislatively‑aligned records. Ensures the description of the AI system is technically accurate, not just administratively tidy. -
Technical Validator
Verifies that the model or logic behaves the way it’s documented to behave. This is the “model validation” function seen in banking and in Canada’s ADM reviews. -
Data Scientist / ML Engineer
Provides evidence for testing, drift monitoring, explainability, and model changes. Without this, “Documented” and “Proven in Practice” collapse into the same thing — which they aren’t.
These roles are the difference between a register that exists and a register that is trustworthy. They’re also the reason this kind of design work shouldn’t be done in isolation. A credible APP 1.7 process needs collaboration across agencies, regulators, legal teams, and technical specialists — not one designer or one department trying to solve it alone.
5. Prototype design and build
Working with Claude Fable 5, I built a working prototype centred on a single design decision: separating "Documented" (system-level paperwork) from "Proven in Practice" (decision-level proof) — because a use case can be fully written up and still fail to produce a real explanation when someone actually asks for one. One assessment generates three outputs: a register entry aligned to DTA's actual field structure, a plain-language citizen-facing disclosure, and an executive summary.
Below is an excerpt from the structural brief used to guide the build — included to show the level of reasoning embedded before any code was written:
```The core problem this tool solves: agencies don't have a consistent way to determine what APP 1.7 requires of them, translate that into something a citizen can understand, and prove the compliance is real and current — not just a document filed once and forgotten while the system keeps evolving.
Layer 1 — System-level compliance: documented once, re-triggered on change.
Layer 2 — Decision-level compliance: happens every time the system actually makes or informs a decision about a real person.
Most agencies will nail Layer 1 and completely miss Layer 2.```
5. Refinement, honesty checks, and deployment
Across several iterations, I added: risk-tiered review (self-certification for low-risk cases, dual technical + legal sign-off for medium/high-risk ones), a role-based access system with four mock logins that actually restrict what each role can do, a timestamped activity log, and a "hollow-disclosure check" — the tool flags when a citizen notice promises an explanation the underlying system can't actually produce.
I also caught and corrected several of my own overclaims along the way — an inferred detail about DTA's reporting method that I'd stated too confidently, a stakeholder card that implied something about people's technical competence I didn't actually know, and a citation about Canada's implementation pulled from a secondary source rather than verified directly. Each correction is a small example of the discipline the tool itself is trying to enforce: don't claim more than you can prove.
The prototype was deployed as a standalone site via GitHub and Netlify. that you can look at here:
You can also check out some screenshots from the prototype below.
The prototype is rough and the UX/UI isn’t polished, but it serves its purpose: giving a first sense of the experience and something concrete to iterate on.
6. A comparative build with Base44
Using everything learned across the research, mapping, and Fable iterations, I rebuilt the same concept in Base44 — a different AI app-building platform — as a comparison point. That build took only a few minutes.
You can access the prototype via this link. It’s behind a free account, but once logged in you can click through the full experience:
The result carried the substance across cleanly, not just the surface. A real sidebar navigation (Dashboard, AI Systems, Assessments, Disclosures, Activity Log, Reference Library, Settings), a donut chart and bar chart on the dashboard, a logged-in identity badge, and role-tagged activity log entries all landed correctly. Most notably, it includes a dedicated Reference Library page citing the actual sources behind this project — APP 1.7, DTA's Standard for Accountability, ISO/IEC 42001, NSW's AI Assessment Framework — each with its own annotation explaining why it's relevant. The Settings/About page preserves the exact "what it demonstrates / what it deliberately doesn't do" honesty framing and the nine-stakeholder map from the original research.
The comparison itself is the real finding, not just a novelty: the deeper thinking — the stakeholder map, the two-layer compliance model, the sourced reference library, the honest limitations — came from the slower, more deliberate research-and-reasoning process with Claude and Fable. That thinking transferred directly into the fast Base44 build and shaped every page of it, rather than the fast build replacing the need for that earlier work. Speed and interface polish are not substitutes for having already done the thinking about the problem — but once that thinking exists, it travels well.
My efforts
-
Conducted independent regulatory research across Commonwealth, Victorian, NSW, and Canadian frameworks
-
Mapped nine stakeholders and four user journeys before any prototype design began
-
Designed the two-layer "Documented vs. Proven in Practice" compliance model
-
Directed multiple structured build iterations with Claude Fable 5, including UX critique-and-improve cycles
-
Caught and corrected several of my own unverified claims during the research and build process
-
Deployed the finished prototype independently via GitHub and Netlify
This exercise didn’t just produce a prototype — it revealed how many moving parts APP 1.7 actually touches.
-
The hardest part is agreement, not the interface.
The most useful thing this prototype does is say plainly what it doesn't solve. That's a harder, more valuable question than any screen design: what would it
take for this to actually be correct, not just internally consistent? -
Mapping the stakeholders changed the scope
Once nine roles were on the table, it was clear no single team could design this alone. -
Paperwork isn't proof.
A tool can ask the right questions and show the gaps. It can't verify a system actually behaves the way it's described — that still needs a technically qualified person involved. -
Excel-based tracking isn't a failure, it's the starting point.
Commonwealth, NSW, and international examples all show the same thing: spreadsheets, email, manual workarounds. That's the shared reality worth building past, together.
-
Co-design across agencies.
A credible APP 1.7 process needs input from the people who actually do this work — compliance officers, legal reviewers, technical validators, and regulators. One agency or one designer can't solve this alone. -
Build on what agencies already have.
A real version of this would likely sit on Microsoft Purview and Power Platform — tools agencies already use — rather than new standalone software. -
Settle the open questions properly.
Whether legal and technical review is needed on every medium/high-risk case, or only genuinely new ones, is a policy decision — not something this prototype should assume.
This was a couple of hours over a two-day sprint by one person. A real solution needs more than that. If there's ever a chance to contribute ground-level thinking like this to the DTA's AI Use Case Register work or the new AI Review Committee — even informally — I'd be genuinely interested in participating. This project kept circling back to one specific gap: compliance teams can write a good disclosure and ask the right questions, but checking whether an AI system actually works the way it's described takes someone with real technical skills — a data scientist or model validator, not a compliance generalist. Canada's own reviews of its Algorithmic Impact Assessment process found exactly this: departments often lack the technical capacity to properly evaluate what they're assessing. Whether the same gap exists here isn't something I know — it's a genuine open question worth checking, not a claim I'm making about Australian agencies specifically.