This is not a user manual. It is the technical architecture reference your architects will read before integration is ever discussed: the declarative workflow schema, the execution mechanics, failure handling and Saga compensations, Cedar policy enforcement, the Evidence Ledger, and the white-glove deployment model. Everything here is lifted from the running system — nothing is illustrative.
Intended reader: an architect performing due diligence. Integration is white-glove and guided — this set exists so a reviewer can audit any claim: every guarantee names the engine phase that enforces it and the ledger event that records it.
The documentation set
Twenty-four documents in six sections. Each document is the single authority for the contract it describes; where one needs another's contract, it links rather than restates.
01 — Architecture
| # |
Document |
Documents |
| 1 |
Why Escepine exists |
The unhandled failure classes that motivated the platform, and the guarantee stack answering each. |
| 2 |
Architecture overview |
System map: services, boundaries, data flow, inherited guarantees. |
| 3 |
Execution engine |
The dispatch loop and per-step pipeline: every phase, its I/O, its failure behavior. |
| 4 |
Sub-SOP orchestration |
Nesting, artifact propagation, bounded regeneration, circuit breaker. |
| 5 |
Implementation notes |
Hybrid runtime composition; why the integration contract is implementation-agnostic. |
02 — Workflow schema
| # |
Document |
Documents |
| 6 |
SOP reference |
Field-level specification of the SOP artifact. |
| 7 |
Step types |
Execution semantics of HUMAN, REASONING, EXECUTION, SUB_SOP. |
| 8 |
Verification blocks |
Criteria, verdicts, the bounded back-edge, the zero-case rule. |
| 9 |
HITL blocks |
Escalation ladders, park conditions, response semantics. |
| 10 |
Tool definitions |
The third authoring artifact: the MCP tool record — schemas, sandbox profile, side-effect class, registration criteria. |
03 — Reliability
| # |
Document |
Documents |
| 11 |
Failure model |
Failure classes, detecting phase, action at detection. |
| 12 |
Saga compensations |
Reverse-order rollback; why retries are insufficient. |
| 13 |
Retry and recovery |
Budget hierarchy, escalation ladder, regeneration caps, circuit breaker, resume-from. |
04 — Governance
| # |
Document |
Documents |
| 14 |
Cedar policy gateway |
Runtime policy evaluation: decision point, ALLOW/DENY flow, attachment. |
| 15 |
Schema validation |
The two structural gates that catch hallucinated tool calls. |
| 16 |
Evidence Ledger |
Events, artifacts, checksums, audit trail. |
05 — Operations
06 — Reference
Reading paths
Conventions
| Convention |
Rule |
| Terminology |
One sense per term, fixed in the glossary. Synonym drift is a defect. |
| Claims |
Every guarantee names the enforcing phase and the recording ledger event. Guarantees without a mechanism do not appear. |
| Excerpts |
Every excerpt carries a caption naming its source artifact. Illustrative examples do not exist. |
| Diagrams |
Structured text in text blocks. No decorative imagery. |
| Quotations |
Blockquotes are reserved for verbatim product and deployment claims. |
| Voice |
Declarative, present tense, system as subject. Written for a hostile reviewer. |
Scope boundaries
| Absent by design |
Reason |
| Getting-started guides, tutorials |
Delivery is white-glove; nobody self-serves into production. |
| SDK and REST API references |
The integration surface is the artifact contract — SOP JSON, Cedar policies, MCP tool definitions — plus HITL signal semantics. All are specified. |
| Pricing and packaging |
Commercial terms live in direct discussion. |
| Comparisons and roadmaps |
The architecture states what the platform guarantees; the reader compares. |
Baseline
All documents describe one engine baseline, reference revision 1.0. When the engine changes, the changelog records it and affected documents are re-verified before the revision ships. Where prose and the Evidence Ledger disagree, the Evidence Ledger is authoritative.
