Record the decision. Don't make it.

The request, and three facts that shaped it

A policy exception is a request to do something outside an existing Compliance policy. The right leaders read it and decide before anything goes ahead, and the decision has to leave a record that holds up later.

In April 2026 the Compliance business owner asked for policy exceptions to live inside the risk register we had launched in March. ECS, AstraZeneca's delivery team in India, which built the app in Power Apps, would build this part too. Three facts shaped the requirements.

First, about 1,600 people in the US business unit could ask for an exception, and about a dozen could see the risk register. Those are the business owner's figures, rounded.

Second, a committee of about ten people decided, and who signed off changed with the exception. Compliance had no rule for how many of them had to agree.

Third, Compliance hadn't approved the workflow itself. The two registers it would sit beside were approved on 16 April.

I wrote the requirements, kept the list of open decisions, and built prototypes so people could react to screens instead of paragraphs.

Let anyone ask without showing them the register

Two ways to take requests were on the table: Microsoft Forms, then a separate app ECS proposed. The business owner turned both down. The people asking for exceptions were senior, and a separate link was one more thing for them to keep track of.

So the design became one app with a Policy Exception tab. Someone who isn't a register member sees that tab and nothing else. I wrote it into the spec: intake inside the app, no external form, no public access, and exception records in their own list, apart from risks and mitigations. Every request still passes single sign-on and a role check.

For a requester, the exception tab had to be easy to find. For a register owner, the risk records had to stay out of that requester's reach. The same sign-on could serve both without making their permissions the same.

Record the decision. Don't make it.

Nobody had written a quorum rule. Not 60 percent, not seven of ten. A system can't enforce a rule the business hasn't made, and it shouldn't guess one.

The business owner proposed that an administrator mark the outcome by hand once the committee had responded. I specified the limits of that role.

Three ways to run the approval

Before the committee structure was settled, I put three options on one slide for ECS and the business owner. One reviewer was simple, but one group decided alone. Two stages in order gave a second check and took longer. Two stages at once was fastest, but it left a question nobody had answered. What if one says yes and the other says no?

Two stages in order was the working idea on 21 April. The structure confirmed on 29 April looks like that option with one change that mattered. The second step records the committee's decision instead of adding a second approval.

Keep the unapproved work off the critical path

Phase 2 held two approved registers, US and Global, and one workflow nobody had approved. ECS's build order put policy exceptions second. The business owner didn't want it holding anything up and wanted it clearly separate from the register.

So I moved the whole workflow out of the Phase 2 requirements table into its own section of the spec, headed "pending Compliance approval". That section says it doesn't block either register. ECS could build what Compliance had approved while Compliance decided on the rest.

Shared where it's safe, separate where it matters

The Global team wanted the same register. By late April the business owner put it at about 95 percent the same, with its own admins, its own leaders and six risk areas instead of three. My April deck proposed one app with two lists that don't mix. The login, app code, review workflow, audit pattern and export template were shared. Records, admin rights, mailboxes, reminder schedules and audit entries stayed separate. Someone who could see the US list couldn't see Global rows, and the reverse.

Policy exceptions were US only, and they got the same treatment, with their own list and their own mailbox.

What the prototypes were for

I built two prototypes before the rules were final. The Figma one gave the request two-thirds of the screen and the decision one-third. It wouldn't let a reviewer decline or ask for more information without writing a reason, and it showed that reason in the audit entry before the reviewer committed. The HTML one showed a request going back to the requester and returning as a second review cycle on the same record, with the earlier events kept.

In the walkthrough, the business owner pointed out that someone seeing it for the first time could mistake the sample requests for real ones. The spec then required test copies to be clearly marked as sample data. After the walkthrough, the business owner asked for the link to share with the team.

Where it ended

Compliance hadn't approved the policy-exception workflow by the last version of the spec I wrote, dated 29 April 2026. That version still marks it "pending Compliance approval". In May 2026 my work moved to the AI Workbench and I handed the requirements over. I don't know whether the workflow was built.

What I can point to is the record. Each version of the spec recorded what changed and whose review drove it. The open questions sat in one list with the date each was raised, ten of them going into the April review. Confirmed decisions and open ones are marked differently in the text, so nobody had to guess which was which.

Map the work before redrawing the screen

In March 2026 the lead for two research-review processes asked me for a prototype. One process handles proposals from outside researchers who want AstraZeneca to support their study. The other runs internal study documents past a panel of specialists. A vendor had already built a Power Apps version that read the PDFs and filled in some fields. Leadership looked at it and said it wasn't agentic at all.

The easy move was to reskin the vendor's form as a chat window. Instead, the same day as the first call, I turned the requirements document and the walkthrough into nineteen FigJam maps: who does what, each process as it ran, swimlanes by role, data flows, decision rules, the system architecture and the pain points at every stage. Then a future-state version of each.

Where it went

The prototype became the research governance assistants, one for each process in a single portal. Each opens on what's overdue, and every answer comes with its next action attached. The AI prototypes part shows the screens. On 1 April they were paused, because nobody had approved a budget for the next phase. Nothing was built.