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 disclose when AI helps make a decision about someone. 94 agencies already had to build their own AI register by June 2026 — each working alone, no shared system, no shared format, everything emailed to the DTA every six months.
I wanted to see whether a compliance process like this could actually be designed around the people it affects, instead of just the regulation it's satisfying. So before building anything, I stopped and asked who's actually affected here, and what each of them needs.
Photo by Ajaykumar Kannan on Unsplash
Here’s how the journey unfolded:
Who's involved, and what they need
APP 1.7 isn't a single-team compliance task — it's a whole-of-system workflow touching nine different roles, from the business owner screening a new system to the citizen who receives the automated decision. I mapped all nine stakeholders and four user journeys before any prototype work started. Different people have completely different experiences of the same regulation, which is exactly why one generic form was never going to work.
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
Completes the full assessment; self-certifies if low-risk, or routes to technical and legal sign-off if medium/high-risk; the system then generates a register entry, citizen notice, and executive summary automatically.
A citizen who's affected by an automated decision
Receives a plain-language explanation of how the decision was made, can ask for the specific reasoning behind their own case, and can request a formal review.
An executive tracking progress before the deadline
Opens a dashboard showing what's covered, what's properly proven versus just documented, and where the gaps are.
The nine roles also made clear that a single request — 'add a disclosure form' — was masking nine different underlying needs, each with different stakes and different proof requirements.
Building and testing the prototype
The prototype centres on one 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 asks for one. One assessment generates three outputs: a register entry, a plain-language citizen notice, and an executive summary, with risk-tiered sign-off. I rebuilt the same concept on a second AI platform as a comparison — the deeper thinking carried across cleanly, confirming that speed and interface polish aren't substitutes for having done the thinking first.
The missing technical roles
The prototype also makes clear what it can't replace: a Technical Validator to verify the model behaves the way it's documented to, and a Data Scientist or ML Engineer to provide evidence for testing and explainability. Without those roles, there's no way to actually tell the difference between a system that's just documented on paper and one that's proven to work the way it says it does.
Here's an excerpt from the structural brief that guided the build, showing the reasoning behind it 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.``
The prototype is deployed as a standalone site via GitHub and Netlify: Disclose — APP 1.7 disclosure & assessment. It's rough and the UX/UI isn't polished, but it gives a first concrete sense of the experience to iterate on.
Rebuilt as a comparison on a second platform: Base44 APP (free account required). The build only took minutes, but everything from the original research was still there — the stakeholder map, the two-layer compliance model, the reference library, the same honest list of what it doesn't do. So the interface was fast to build, but the thinking behind it wasn't something the second tool could shortcut. That had to happen first, regardless of which platform built the front end.
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
The hardest part of a problem like this is agreement, not the interface. 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 reviewer. I also caught and corrected several of my own overclaims along the way, which is its own small case for the discipline the tool is trying to enforce:
..don't claim more than you can prove. A credible version of this needs co-design across agencies — no single team can solve it alone.