A model that scores well on a held-out well is not deployed. It is a checkpoint on a GPU in someone else's data centre. Getting it to run inside a client's own geoscience platform, where an interpreter can call it on a live well without touching our infrastructure, is a separate project with its own schedule and its own owners. Our companion note lays out the architecture that integration produced once it worked. This piece is the schedule that got us there, and the honest record of which beat on it governed the pace.
We planned it as a three-month runway for a major operator in Oman: a research sinusoid-detection model, built over the earlier phases of the engagement, moved into the operator's in-house platform through a DEV environment, a STAGING environment, and a one-well demo. The plan is unremarkable to read. That is the point. The interesting part is not the code beats, which went roughly as scheduled. It is the single client-side beat that did not, and how a schedule with clean owner columns still hangs on the one row you do not control.
January: requirements before a single line of integration
The first month has no integration in it at all. It is provisioning and agreement, and both halves matter.
On our side, the RealAI track, January was preparation we could mostly drive ourselves. Connect to the client-platform VPN, because everything downstream runs inside their network, not ours. Obtain the SDK information and API templates to build the greenfield integration against, since a research model that emits sinusoid parameters is useless to the platform until it speaks the platform's call convention. Share a requirements-gathering questionnaire, so the interpreters who would use the tool told us what they needed before we wrote it. And, jointly with the client's IT and geomatics people, lock the feature list for v1.0.0, the first integrated release. Naming a v1.0.0 is a discipline, not a formality: it draws a line around the January feature set so February integrates a fixed target instead of a moving one.
Then there is the client-side beat, the client-IT track. For us to build a greenfield integration inside their platform, they had to create a DEV copy of it for us to build in: a sandbox that mirrors production closely enough that what works in it will work live, isolated enough that our half-finished code cannot touch a real well. That beat was recorded with a status of Pending.
That one word is the whole story of the runway. Nothing about the DEV greenfield copy is hard. It is a routine act of provisioning inside the client's own environment. But it is entirely on the client side of the owner column, it is a prerequisite for every code beat that follows, and it moves at the speed of a partner's internal access process rather than an engineering task we can grind through. A code beat that slips, we can recover with a weekend. An access beat that stays Pending, we can only wait on.
February: the integration that is all downstream
February is where the engineering lives, and every beat in it sits behind the January gate.
First, a narrow test: run the RealAI API against the platform on a few wells, enough to prove the call convention and the round trip before committing to the full integration. Then integrate the Sinusoids API into the DEV environment proper, so a platform user could invoke sinusoid detection the way they invoke any other platform function. Then promote that integration from DEV into STAGING.
The DEV-to-STAGING split is not bureaucracy. DEV is where the integration takes shape and is allowed to be broken. STAGING is explicitly the environment for load testing and security. A sinusoid model that answers one query in a notebook is a different object from one that holds up when the platform sends it real traffic under real access controls. Load testing asks whether it survives concurrency and volume; security asks whether it behaves inside the client's network boundary the way their controls require. Those are STAGING questions, not DEV questions, and collapsing the two environments is how a demo that worked becomes a rollout that falls over. Once STAGING held, the link went to the shareholders.
Read the February list again and notice what it assumes: a DEV environment to integrate into. Every February beat is a code beat, and every code beat is downstream of the January DEV greenfield copy. Test the API against the platform needs the DEV copy. Integrate the Sinusoids API into DEV is the DEV copy. Promote to STAGING promotes from the DEV copy. There is no honest way to start February while January's provisioning beat is still Pending. The instrument below makes that dependency literal.
The two tracks run in parallel on paper; in practice one gates the other. Toggle the access state to Provisioned and the whole February and March span lights up as reachable. Leave it at Pending, its recorded state, and every code beat greys out, not because the code is not ready but because it has nowhere to run. The orange node is the argument: a single client-side provisioning beat, on the critical path, with four code beats waiting behind it.
March: one well, and a decision
March is deliberately small. Build a prototype on at least one well section, share the link with stakeholders, gather feedback and feature requests. The framing in the plan is exact: a demo to show accepted integration and seek stakeholders' confidence and approval. Not a launch. A checkpoint where the people who own the platform see the model working inside it, on their well, through their environment, and decide whether v1.0.0 is what they want to carry forward.
Scoping March to one well is the right conservatism. The earlier phases had already shown the model generalises across wells; March is not a modelling test, it is an integration and trust test, and one well section is enough to prove the model runs end to end inside the platform while keeping the demo legible to a room of stakeholders. The value at this beat is not a metric. It is a geoscientist watching the tool return sinusoids on a well they know, inside the software they already use, and believing it.
Where the risk actually sat
The lesson is that this runway's owner columns were clean and its critical path still ran through the one row we did not own. If you build a schedule like this, do not track it as a code project with a provisioning footnote. The dependency runs the other way: the provisioning beat is the spine, and the code beats hang off it.
Two moves follow. Pull the client-side access beats as early as they will go, ideally before kickoff, because they run on a process you cannot control or compress. And give the gate beat its own colour in status reports, the way the instrument does, so a client-side Pending reads as a risk to the whole runway and not as one grey row in a list of green ones. A late code beat is a problem you can work. A Pending access beat is one you can only surface early and wait on, and the runway that hides it behind a tidy owner column is the one that surprises everyone in February.
Limitations
This is one integration runway from one engagement, a three-month DEV-to-STAGING-to-demo plan for one operator's platform, not a general integration methodology. The month-by-month beats are drawn from the Phase-3 integration-timeline sheet and reported as planned; the Pending status of the DEV greenfield copy is the recorded state at planning time, and this note does not claim to document if or when that provisioning cleared. The runway covers moving an already-built model into a platform; it says nothing about the modelling work that preceded it or the capability-transfer work that followed, both of which live in their own notes. The instrument's Provisioned toggle is an illustrative reader control, not a claim that the access ever resolved. A different platform or access process would move the beats around; what generalises is the shape, that a client-side access beat can sit on the critical path of a schedule that otherwise looks like ours to run.
