Write Access Is the First Deliverable
The first two weeks of an embedded engagement are not spent on discovery. They are spent acquiring write access to the systems the work runs on, and the…
Day fourteen of an embedded engagement is a checkpoint with two items on it: write access to the systems the work runs on, and the name of the one person who can approve a change to production. Both get treated as administration. They are the first deliverable. An engagement runs eight to sixteen weeks, and day fourteen is the end of the first quarter of the short one, the last day a credential arrives early enough to build against. An engagement that reaches it holding neither ships a prototype, however good the specification is. Discovery has instruments and they work. One is a five-criterion rubric that scores a candidate workflow and returns build now, wait, or never. The other turns a complaint into a buildable specification. Interviews, case files, historical adjudications, a query against a warehouse: every step in both is a read. Discovery runs on permissions nobody thinks twice about granting. A finished specification fails the opposite way from a strategy deck, which names a desired state and never the system that reaches it. The specification is correct the day it is delivered, and then it waits, because the write request went into a queue and a queue has no date. A field the pipeline depends on gets renamed. Nobody edits the document. It becomes accurate about a system that no longer exists. In every engagement we have run, read access has arrived in days, because granting a read obligates nobody to accept a consequence. Write access is a different request. A deploy key to the repository that runs the nightly job, permission to insert a row into a production table: each asks somebody to own a change not yet made. That is not a ticket. It is an underwriting decision. Read requests are approved by the person who holds the credential. Write requests are approved by the person who owns the outage. That person is frequently not in the room, and occasionally does not exist at all, with a veto in three functions and an approval in none. A team without that name does not stop working. It builds against a copy, and a copy never produces a permission error or a record another process locked moments earlier. Those are not edge cases. A prototype is not a smaller version of the system. A prototype is the portion of the system that could be built without asking anyone to sign for anything. A bank under change control, a healthcare operator inside HIPAA: handing an outside team a production write in two weeks would be a control failure, and the deliverable there is the named path to one. The change window, the engineer who holds the write, the person who approves what that engineer runs. We have shipped inside that shape. A path with no name on any step is not a slower approval. It is the absence of approval, wearing a calendar invite. The first classifier in an AI studio buildout processed a real submission on day 18 of a twelve-week engagement that shipped several products. The number that matters is not the count and not twelve. It is 18. Nothing touches a real submission that early unless the credential exists, the queue is readable, and there is somewhere to write the result. The access work was not in parallel with the build. It was the first thing built. Ask on day one. Name the system and name the write. A question about ownership returns a title. A request for a credential returns whether the title is true. The answer arrives as a name, as a name that proves wrong, or as a meeting scheduled to determine the name. The last one is not a step toward the answer. It is the answer. We ask for the write credential and the name of the approver in the first week, before the workflow is scored and long before a model is chosen. A workflow that scores well with nobody who can authorize a change is not a build now. It is a wait. The precondition is not the data. It is the permission.