- shape
- Operator console · authenticated service API · Google Cloud scheduling → single-flight launcher → capacity-aware parallel fan-out to up to three engines → deterministic rollup → operator review.
- contract
- Each engine is a separately deployed service behind one adapter interface: certificate in, result plus evidence out. OpenRouter generation and deterministic domain gates can evolve behind that boundary; the orchestrator owns retries, service-aware capacity and skip rules.
- failure semantics
- Every failed attempt remains in history and can be retried. Only an engine failure still unrecovered after its retry policy forces a fail-closed aggregate, prevents clean approval, and routes the run to technical review. Job state is written durably before acknowledgement, so a client polling for a result never lands on an empty run.
- concurrency
- Single-flight per certificate and per-engine capacity budgets, both enforced with Postgres advisory locks, so two instances can’t duplicate work and a slow engine can’t starve the others.
- where ai sits
- All three engines use OpenRouter for extraction, semantic resolution or structured specialist judgment, bounded by deterministic rules and validation gates. The cross-engine rollup is deterministic; optional operator synthesis is non-blocking.
- evidence
- Every attempt, engine verdict and review decision is a row. Per-engine task states stream to the console in realtime; approved reports keep the full evaluation payload.
- impact
- A certificate that took a specialist a working session now completes in about three minutes, the same shape every time. Three reviewers supervise instead of execute.
