Case Study Sapey / Nolte.io · Free Range Studios · 2026
A California regulatory compliance platform with three organisations that could not agree on what had been built. No neutral ground. No shared truth. I stepped in, ran the API tests myself, surfaced six SOW discrepancies, and rebuilt the factual record from scratch - so the project could move forward on evidence, not claims.
01 / Context
Sapey is a Safe Execution Control Plane - 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 not product features. They are regulatory determinations that affect real patient care decisions in licensed facilities.
The system has two technical layers built by two different organisations. Free Range Studios (my organisation, BetaCraft/sorigin.com) built the backend policy engine - the Safe Execution Control Plane itself - using Neo4j and Gemini, with a production API that processes Title 22 events. Nolte.io built the UI and the integration layer that connects the frontend to the backend. Roddy Radnia is the client, holding both teams to account for the overall system.
Client
Product owner. Holding both technical parties accountable. Deadline: end-of-May demo with all three Title 22 outcomes verified.
Free Range Studios (my org)
Mayuresh Soni (lead, travelling), Chetan Dhandal (engineer), Aakash Dhar (PM, stepped in). Built the production API processing Title 22 events.
Nolte.io (third party)
Yanna Lopes, Hector Sanchez. Built the verification console and integration layer connecting frontend to the Free Range API.
02 / The situation I stepped into
I stepped in as PM during Mayuresh's travel absence. 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.
Nolte.io's position: Free Range 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.
Free Range's position: All three Title 22 outcome states had been demonstrated to Hector from nolte.io in an April 23 demo. The work was done. The claim that it was not was factually incorrect.
Both teams were presenting their positions to Roddy. Roddy 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. The only way to resolve it correctly was to bypass both parties' claims entirely and go directly to the evidence.
03 / The first move: test it myself
The fastest way to resolve whether Free Range had delivered on Title 22 outcomes was not to read the meeting notes or ask either team. It was to go directly into the production API and test all three outcome states myself.
I accessed the Free Range production endpoint via Swagger UI at the live CloudFront URL, using the API key and the correct payload structure. The endpoint was POST /api/v3/events/rio. The key technical details that had to be right: rio_version: "1.0" (not "3.0", which returns a 422), canonical_concept_ids nested inside interpretation not at the root, and evidence_fields inside event.
I ran all three fixtures. Every one returned a verified decision in production.
All three Title 22 outcome states were live and working in production. Nolte's claim that Free Range had not delivered on Title 22 outcomes was factually incorrect - as confirmed by the April 23 transcript where Hector had been present for the demo, and now confirmed again by live production evidence.
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 of 3 versus the documented 2. These were genuine gaps that needed fixing. The point was not that Free Range was perfect - it was that the specific claim of non-delivery was wrong, and now there was evidence to prove it.
Why this mattered
Going into the API myself meant the evidence was mine - not relayed from Free Range, not interpreted by nolte.io. Decision IDs, timestamps, payload structures, discrepancies included. That is the kind of evidence that holds up in a three-party dispute. Nobody 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 | AdmissibilityGate 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, SAP-327 (listed as billable Phase 2.2 work) is already delivered and should not be in scope. | Medium |
| D-02 | Nolte not consulted on Phase 2.2 scope: The SOW was written without input from nolte.io despite active integration interdependency. Nolte cannot sign off on what they were not part of scoping. | High |
| D-03 | Nolte reconciliation marked out of scope: The SOW explicitly excludes nolte integration work despite the Phase 2.2 demo requiring both systems to work together. This is not a deferral - it is a gap that 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 confirmed by Roddy on the May 18 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 Roddy 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 Roddy and Yanna took a different approach: acknowledge the gap that existed, present the evidence of what was working, flag the documentation discrepancies honestly including Free Range's own, and frame the next steps as a joint effort to establish shared ground truth before the Thursday call. The April 23 transcript - where Hector had been present for the Title 22 demo - was included as an Otter recording link. Not as a weapon. As context.
What the email did not do
The claim that Free Range had not delivered was incorrect. The email corrected the record without characterising nolte's position as bad faith.
What the email did do
Production decision IDs, the April 23 transcript reference, the documentation gaps found during testing - all cited specifically, all verifiable independently by anyone on the thread.
The MoM documents I produced from the May 18 and subsequent calls followed the same discipline: strict grounding in transcript content, no inference, no embellishment, a Client Sentiment section added at Roddy's implicit request to make his engagement visible to both teams. Every action item named, owne, and dated. Every unresolved item explicitly flagged.
06 / Outcomes
Allow, Deny, Defer - all confirmed with production decision IDs. The claim of non-delivery was corrected with direct evidence, not 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.
MoM documents grounded strictly in transcript content gave all three parties a single authoritative record of what had been said, decided, and committed to. No more competing versions of history.
The five missing evidence fields and the tasks_created count discrepancy were genuine issues in Free Range's own documentation. Flagging them proactively - rather than hiding them - was the right call. It built credibility rather than undermining it.
With the delivery dispute resolved and the SOW issues surfaced, the project moved forward. An independent audit by a reviewer named Thomas was included in the Phase 2.2 scope as a trust-building measure between all parties.
07 / Reflection
The hardest 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. Nobody wins those.
Going into the API myself was the move that changed everything. Not because it proved Free Range right in some triumphant way - we had our own documentation gaps that I surfaced in the same breath - but because it replaced two competing narratives with a single set of facts that everyone could verify independently. Decision IDs do not lie. Timestamps do not have a perspective.
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 a Free Range problem or a nolte problem - it was a document problem that would have created a contractual commitment nobody could meet. Surfacing it before the Thursday call, rather than letting Roddy sign something unworkable, was the most valuable thing I did 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 Chetan - 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 unimpeachable. That is what technical PM actually means in practice.