Case Study Regulatory Compliance Platform · US Healthcare · 2026
This engagement centred on a US regulatory compliance platform where three organisations could not agree on what had been built, with no shared record to settle it. I stepped in, ran the production API tests myself, surfaced six SOW discrepancies, and rebuilt the factual record so the project could move forward on evidence rather than claims. Names and identifying details are withheld here; a detailed account is available on request.
01 / Context
The platform is a policy decision engine - a regulatory compliance system that processes clinical events from residential care facilities against California Title 22 RCFE rules. When a care event occurs, the system evaluates it against policy and returns one of three possible decisions: Allow, Deny, or Defer. These are regulatory determinations, and they affect real patient care decisions in licensed facilities.
The system has two technical layers built by two different organisations. My organisation (BetaCraft, the backend team) built the policy engine using Neo4j and Gemini, with a production API that processes Title 22 events. An integration partner built the UI and the layer that connects the frontend to the backend. The client, the product owner, held both teams to account for the overall system.
Client
Holding both technical parties accountable. Deadline: end-of-May demo with all three Title 22 outcomes verified.
Backend team (my org)
Account lead (travelling), one backend engineer, and me as PM, stepping in. Built the production API processing Title 22 events.
Integration partner (third party)
Two-person team. Built the verification console and the integration layer connecting frontend to the backend API.
02 / The situation I stepped into
I stepped in as PM while the account lead was travelling. What I found was a project that had technically been running but had accumulated a credibility problem between the two technical teams - and that problem had reached the client.
The integration partner's position: the backend team had not delivered on Title 22 outcomes. The integration work was blocked because the backend was not ready. The SOW for Phase 2.2 was premature.
Our position: all three Title 22 outcome states had been demonstrated to the partner's engineer in a recorded April demo. The work was done, and the claim that it was not was incorrect.
Both teams were presenting their positions to the client, who was waiting for a resolution. A Thursday call was scheduled. I had roughly 48 hours.
The real risk
This was not a technical dispute. It was a trust breakdown between two organisations, with a client in the middle who was about to make contract and payment decisions based on whoever presented their case most convincingly. Resolving it correctly meant setting both parties' claims aside and going directly to the evidence.
03 / The first move: test it myself
The fastest way to resolve whether the backend had delivered on Title 22 outcomes was to go directly into the production API and test all three outcome states myself, rather than reading meeting notes or asking either team.
I accessed the production endpoint via Swagger UI and constructed the event payloads by hand. Getting a valid POST through meant reading the API spec properly: the right schema version (the wrong one returns a 422), concept identifiers nested at the correct level, and evidence fields placed inside the event object rather than at the root.
I ran all three fixtures (ALLOW, DENY, DEFER) and every one returned a verified decision in production.
All three Title 22 outcome states were live and working in production. The claim of non-delivery did not hold - the April demo transcript, where the partner's engineer had been present, said the same thing, and the live production evidence now confirmed it independently.
I also caught two real discrepancies between the fixture documentation and the live API - five evidence fields missing from the document, and a tasks_created count that differed from what was documented. These were genuine gaps in our own documentation that needed fixing. The point was not that our side was flawless - it was that the specific claim of non-delivery was wrong, and there was now evidence for it.
Why this mattered
Going into the API myself meant the evidence was first-hand rather than relayed by either party to the dispute. It included decision_id values, timestamps, payload structures, and the discrepancies. That is the kind of evidence that holds up in a three-party dispute, because no one could question whose version of events it was.
04 / The second move: read the SOW properly
While the API tests settled the delivery dispute, a second problem was developing in parallel: the Phase 2.2 SOW that had been circulated was not fit to sign. I ran a full discrepancy analysis against the meeting record and found six issues.
| # | Discrepancy | Severity |
|---|---|---|
| D-01 | Internal check count: Executive summary says 4 of 5 checks delivered; project definition paragraph says 5 of 5. Same audit, same document, two different numbers. If 5 of 5 are done, a ticket listed as billable Phase 2.2 work is already delivered and should not be in scope. | Medium |
| D-02 | Partner not consulted on Phase 2.2 scope: The SOW was written without input from the integration partner despite active integration interdependency. They cannot sign off on what they were not part of scoping. | High |
| D-03 | Partner reconciliation marked out of scope: The SOW explicitly excludes the partner's integration work despite the Phase 2.2 demo requiring both systems to work together. That gap makes the demo impossible as scoped. | High |
| D-04 | 9-week timeline incompatible with end-of-May demo: The SOW proposes a 9-week delivery window. The demo deadline the client had confirmed on a recorded call is end of May. These two dates cannot both be true. | Critical |
| D-05 | Domain expert hire not addressed: Raised in previous calls as a dependency. The SOW neither includes it nor formally defers it. | Low |
| D-06 | Three-fixture demo requirement not covered: The most pressing near-term deliverable - three Title 22 fixtures for the end-of-May demo - has no home anywhere in the SOW. It jumps straight to the broader expansion without addressing the immediate deadline. | High |
The critical one
D-04 was the item that had to be on the table before Thursday. A SOW proposing a 9-week delivery window when the client had confirmed an end-of-May demo deadline was not a minor alignment issue - it was a document that could not be signed without creating a contractual commitment that was already impossible to meet.
05 / The communication layer
With the API evidence and the SOW analysis in hand, I had to decide how to communicate it. The temptation in a three-party dispute where your own organisation is being accused of non-delivery is to be defensive - to lead with the evidence that proves the other party wrong and let the facts do the work.
That is the wrong move. It turns a project governance problem into a blame conversation, and the client ends up managing two teams arguing rather than getting a resolution.
The email I drafted to the client and the partner's lead took a different approach: acknowledge the gap that existed, present the evidence of what was working, flag the documentation discrepancies honestly including our own, and frame the next steps as a joint effort to establish shared ground truth before the Thursday call. The April demo recording - where the partner's engineer had been present - was included as a link, offered as context rather than as ammunition.
What the email did not do
The claim of non-delivery was incorrect. The email corrected the record without characterising the partner's position as bad faith.
What the email did do
Production decision IDs, the April demo recording, the documentation gaps found during testing - all cited specifically, all verifiable independently by anyone on the thread.
The minutes I produced from that call and the ones that followed kept the same discipline: strict grounding in transcript content, no inference, no embellishment, and a client-sentiment section added so the client's engagement was visible to both teams. Every action item was named, owned, and dated; every unresolved item was explicitly flagged.
06 / Outcomes
Allow, Deny, Defer - all confirmed with production decision IDs. The claim of non-delivery was corrected with direct evidence rather than counter-claims.
All six surfaced, severity-rated, and communicated before anyone signed anything. The critical timeline conflict was the most important - it prevented a contractually impossible commitment from being made.
Minutes grounded strictly in transcript content gave all three parties a single authoritative record of what had been said, decided, and committed to - replacing the competing versions of history.
The five missing evidence fields and the task-count discrepancy were genuine issues in our own documentation. Flagging them proactively, in the same email that corrected the record, built credibility rather than undermining it.
With the delivery dispute resolved and the SOW issues surfaced, the project moved forward. An independent third-party audit was included in the Phase 2.2 scope as a trust-building measure between all parties.
07 / Reflection
The hard part of this engagement was not finding the evidence - it was the discipline to go looking for it before communicating anything. The instinct when your own organisation is being accused of non-delivery is to respond immediately, to assert, to defend. That instinct, if followed, turns a project governance problem into a reputation argument, and nobody wins those.
Going into the API myself was the decisive move - not because it proved our side right in some triumphant way (we had our own documentation gaps, and I surfaced those in the same breath), but because it replaced two competing narratives with a single set of facts that everyone could verify independently. Decision IDs and timestamps read the same to all three parties.
The SOW analysis mattered for the same reason. The critical discrepancy was the 9-week timeline against an end-of-May deadline. That was not one party's problem or the other's - it was a document problem that would have created a contractual commitment nobody could meet. Surfacing it before the Thursday call, rather than letting the client sign something unworkable, was where I added the clearest value on this engagement.
The engineering background was the enabler here. A PM without the technical depth to read a Swagger spec, construct a valid nested API payload, understand what a 422 validation error means, and interpret the response fields would have had to relay the question to an engineer who was a party to the dispute - and wait for an answer that might or might not be impartial. Going in directly meant the evidence was first-hand. That is what a technical PM is for.