Current Status Note

This document began as the pre-execution verdict for the first KES extraction cut.

That first cut has now been executed:

• canonical KES runtime: services/svc-kes
• retired host: old colocated KES HTTP routing in svc-tenders
• removed compatibility layer: former services/svc-tenders/src/kes/*

References below to former svc-tenders KES paths are historical unless a line explicitly describes the current extracted runtime.

Recommended Direction

Proceed with KES runtime/bootstrap prep next, while keeping the event backbone shared in the first extraction cut.

That is the safest truthful direction based on current code reality.

What The First Extraction Cut Included

• KES runtime/server bootstrap in services/svc-kes
• KES route registration and KES route support in svc-kes
• KES contracts and validation in svc-kes
• KES persistence in services/svc-kes/src/kes/repository.ts
• KES-owned tables and writes for:
  • kes_orchestrator_cases
  • kes_orchestrator_tasks
  • kes_orchestrator_inspections
  • kes_orchestrator_payments
  • kes_orchestrator_events
  • kes_orchestrator_process_maps
• KES control-plane, process-map, case/task/inspection/payment HTTP surfaces

What The First Extraction Cut Must Leave Shared

• Gateway seam in services/api/src/routes/kes-orchestrator.ts
• Auth ingress and /auth/me resolution
• KYC/signature ingress enforcement
• Kafka idempotency store
• Outbox relay in services/svc-tenders/src/kafka/kesOutboxRelay.ts
• Domain-event consumer in services/svc-tenders/src/kafka/kesDomainEventConsumer.ts
• DLQ and replay tooling
• API-side proxy event publication for kes.orchestrator.events

What Is Not A Blocker Now

• Keeping kes.orchestrator.events as a shared operational topic
• Keeping proxy-event consumption shared
• Keeping idempotency storage shared
• Keeping outbox relay and domain-event projection consumers shared
• Keeping projection rebuild and DLQ replay outside the first KES runtime

What Blocked Runtime/Bootstrap Prep Then

• No event-backbone blocker was found that by itself prevents KES runtime/bootstrap prep.

• The remaining blockers are narrower and operational:

  • root startup/runtime orchestration still needs a real KES copy-first bootstrap path when the team chooses to execute it
  • shared-shell ingress dependencies for KYC/signature remain intentionally shared and must be carried forward honestly
  • migration ownership and topic/projection ownership are still mixed enough to block full independence claims, but not first-cut runtime prep

What Still Blocks Full Independence Later

• Ownership transfer for outbox publication runtime
• Ownership transfer for domain-event consumers and projection tables
• Clear KES-local rebuild story for projections
• Clear topic ownership and DLQ replay ownership

Clear Verdict

The first extracted KES runtime should be domain-runtime-first, not event-backbone-first.

Move the KES HTTP runtime, route/support surface, contracts/validation, and persistence slice first. Leave Kafka, outbox, projection, idempotency, and replay infrastructure shared during the first cut.

Notes

• This is not a claim that KES is fully independent.
• This is a claim that runtime/bootstrap prep is now credible without first pulling the whole event backbone into KES ownership.