"Escepine is deployed as a white-glove service within your staging environment. The execution plane is containerized and runs locally during evaluation, then deployed to your VPC for production. This ensures zero data egress and complete air-gapping."
The deployment model is white-glove because the plane's guarantees depend on correct placement: inside your perimeter, against your tools, under your policies. The model has two phases — a staging pilot that proves the architecture on your real workflows, and a production deployment that moves the validated baseline into your VPC.
Staging pilot — 48 hours
| Phase | Duration | What happens |
|---|---|---|
| Discovery and workflow mapping | Day 1, first half | Your procedures map to SOP candidates; success criteria are agreed |
| Engine deployment | Day 1, second half | The plane deploys into your staging environment — containerized, locally running |
| Stress execution | Day 2, first half | Your real workflows run against the plane: happy path, failure injection, HITL gates |
| Architecture review and handoff | Day 2, second half | The evidence trail from the stress runs is reviewed with your architects; the baseline is handed off |
What the pilot proves
| Claim | Proven by |
|---|---|
| The plane executes your workflows | Your SOPs, running in your staging environment |
| Governance is runtime behavior | The ledger trail from the stress runs — policy events, verdicts, compensations |
| Failure is safe | Failure injection: deterministic failures trip the circuit breaker, partial runs compensate |
| Humans are in the loop | HITL gates exercised end to end — escalation, park, resolution |
| Your data stayed put | Zero egress, verified in review |
Production deployment
| Property | Semantics |
|---|---|
| Templates | Containerized deployment templates — Terraform and Helm — for AWS, GCP, and Azure |
| Ownership | You own the infrastructure; the plane runs inside it |
| Boundaries | The plane lives in your VPC; your data does not leave it |
| Updates | Delivered as versioned engine releases, re-validated against the ledger baseline |
Air-gap posture
| Asset | Where it lives |
|---|---|
| SOPs, Cedar policies, tool definitions | Your perimeter |
| Workflow state and checkpoints | Your perimeter |
| Evidence Ledger | Your perimeter |
| LLM credentials | Your perimeter, injected at runtime |
| The engine itself | Your perimeter, as containers |
Nothing in the operating model requires your data to leave your control. The only egress in the system is the LLM inference call itself, pointed at the provider you configure — and that call's parameters, not its payload, are what the ledger records.
Exit criteria
The evaluation ends when the pilot's evidence answers the questions it exists to answer:
| Question | Answered by |
|---|---|
| Does the plane execute our workflows correctly? | Stress-run ledger trails |
| Do the guarantees hold under failure? | Failure-injection results — breaker, compensations, parks |
| Can our operators run it? | HITL exercises and canvas walkthroughs |
| Can our auditors audit it? | Chain verification over the pilot's evidence |
| Can it live in our perimeter? | The pilot already did |