Substitute, execute, reconstruct is the three-step method that lets AI run on confidential enterprise data: sensitive values are substituted for structure-preserving stand-ins before the work leaves your systems, the model executes on that substituted version, and the result is reconstructed back into your original context locally.
Enterprises are not short on AI ambition; they are short on data they can safely put in front of a model. When the work involves contracts, patient records, or operational documents, the usual answer is to keep the data away from the model entirely, which also keeps the value away. Substitute, execute, reconstruct is the method that breaks that trade-off: it sends the model the work’s structure, not the raw values, and rebuilds the answer where your data already lives.
What does substitute, execute, reconstruct mean?
Most explanations stop at the headline: the model never sees your real data. That is true, but it skips what each step actually does. Every step has a distinct job, and each one decides whether the workflow comes back finished or comes back as a chore someone has to untangle by hand.
The three steps map to three plain questions. What did you send instead of the real values? What did the model do with it? And how did the answer get back into your world? Read in that order, the method stops being jargon and starts being a checklist you can run against any confidential AI workflow.
Step 1: Substitute the values, keep the structure
This is where the approach either holds or falls apart, and the difference comes down to one thing: structure.
Plain masking removes the sensitive value and leaves a hole. A name becomes [REDACTED]. A price becomes XXX. A clause naming a specific counterparty becomes a gap the model guesses around. The document is now safe and also incoherent, because the model is reading a page full of blanks and cannot reason about relationships that no longer appear on it.
Structure-preserving substitution. It replaces each sensitive value with a stand-in that keeps the shape of the original. A company name becomes a different but consistent company-shaped token. A figure becomes a figure that holds its place in the table and its relationship to the other figures. Contract indentation, the row-and-column logic of a spreadsheet, the ordering of steps in an operational note: all of it survives. What leaves is the identifying content. What stays is everything the model needs to do the task.
So the question that matters here is what you kept, not just what you hid. A good substitution keeps the work intact and lets the values go, which is the line between a redacted blank and a coherent task the model can actually complete.
Step 2: Execute on the substituted version
Now the substituted version goes to the model, and this is the step where the least changes. You run the model you already chose: an external frontier LLM, an on-prem open-weight model, a retrieval pipeline, or an agent that was built around your workflow. It executes on the substituted data much as it would on the original, because from its point of view the task still reads as complete and consistent.
The reasoning a model does over a substituted contract tracks the reasoning it would do over the real one, since the relationships it reads from are still in place. Meanwhile the original values are absent from this step. They never left the environment where they live. What went out was the work, not the record, and that separation is the whole point: you get the model’s full capability without putting confidential values in front of it. The principle behind this is well established: differential privacy, as Penn’s Aaron Roth explains, lets a system surface representative patterns while preventing anyone from revealing information about a specific individual.
Step 3: Reconstruct the answer in your context
The model returns a result, but that result is written against the substituted version. It refers to the stand-in names, the stand-in figures, the placeholder clauses. On its own it is not yet something your team can use.
Reconstruction maps it back. The stand-ins resolve to the real values in the real context, so the output arrives as a finished business document instead of a draft keyed to tokens nobody recognizes. A reviewed contract reads against the actual counterparty and the actual numbers. A summarized report names the real metrics. The reviewer opens it and sees their own document, completed, rather than a puzzle to reassemble.
This step is what makes the method worth running. Without it you would hold a safe result that still needs manual translation, which is most of the effort you were trying to skip. With it, you reach Workflow Closure: the work is actually done, in place, and ready to use.
How the three steps run in place
A fourth idea wraps the other three, and it is easy to miss because nothing visibly moves. The whole sequence runs inside the environment you already operate, whether that is a cloud tenant, an on-prem cluster, or an air-gapped network. The substitution mapping and the reconstruction both happen locally, held in a Local Token Vault, so your infrastructure does not have to be rebuilt to accommodate the method. Regulation points the same way: GDPR Article 32 requires technical and organizational measures appropriate to the risk, and it names pseudonymization and encryption explicitly. Substituting real values with structure-preserving stand-ins is the same trade the Royal Society and Alan Turing Institute describe for synthetic data: privacy and fidelity move together, so the aim is a faithful stand-in rather than a blank.
Running in place matters because the alternative, routing data through some new external service to get the benefit, reintroduces exactly the LLM Data Egress you were avoiding. Keeping the flow local is what makes the first three steps honest. The work goes out as structure; the values and the mapping stay home. Together, steps three and four describe a Restorable AI Data Boundary, where the answer comes back inside rather than leaving for good.
Substitute, execute, reconstruct versus plain masking
The clearest way to see the difference is to line the method up against the redaction approach most teams reach for first.
Masking and substitution both keep raw values off the wire. The gap opens after that: masking hands the model a blanked-out page and hands your team a translation job, while substitution hands the model a complete task and hands your team a finished artifact.
A quick self-diagnostic
Run your current confidential AI workflow through these questions. If you answer no to more than one, the method is worth a closer look.
- When you strip sensitive values, does the document still read as a coherent task, or does it become a page of blanks?
- Do the real values ever cross the boundary out to the model, even briefly in a log or a cache?
- Does the model’s answer come back ready to use, or does someone re-key it against the originals by hand?
- Does the substitution mapping stay inside your environment, held somewhere you control?
- Could you run the same flow unchanged in an air-gapped network if a regulator asked?
Where it fits in CUBIG’s operating layer
Substitute, execute, reconstruct is the engine under sensitive AI workflow enablement. The pillar describes what the practice is for; this article is how it actually runs. In production, the four steps are delivered by a Context-Preserving Data Layer for AI, in CUBIG’s case LLM Capsule, which handles the substitution on the way out and the reconstruction on the way back. It runs on the CUBIG Syntitan platform, so the same boundary applies whether the workflow reads a contract, a spreadsheet, or a scanned document across a Multimodal AI Data Boundary. The mechanism is the product; the middleware is where it lives.
LLM Capsule is the layer that runs this loop for you. It substitutes the sensitive values, lets your model execute on the structure, and reconstructs the real result inside your environment.
