KES Persistence Classification

Historical Status Note

This note captured KES persistence before extraction and compatibility cleanup completed.

Current truth:

• canonical KES persistence now lives in services/svc-kes/src/kes/repository.ts
• the old colocated KES HTTP host is retired
• the former services/svc-tenders/src/kes/* compatibility layer is removed
• shared backbone workers still remain in services/svc-tenders/src/kafka

Date: 2026-03-17 Sprint: Cleanup Sprint 11

Purpose

This note classifies the KES persistence still rooted in:

• services/svc-tenders/src/repository.ts

VERIFIED code evidence

Persistence still lives in the root repository

Representative methods:

• countKesOrchestratorCases
• listKesOrchestratorCases
• getKesOrchestratorCaseDetail
• getKesOrchestratorCaseProjection
• getKesOrchestratorProcessMap
• upsertKesOrchestratorProcessMap
• createKesOrchestratorCase
• approveKesOrchestratorLandowner
• publishKesOrchestratorAuction
• confirmKesOrchestratorFunding
• assignKesOrchestratorTask
• submitKesOrchestratorInspection
• requestKesOrchestratorPayment
• approveKesOrchestratorPayment
• settleKesOrchestratorPayment
• closeKesOrchestratorCase
• listKesOrchestratorSuggestions

KES also has explicit event/runtime components

Evidence:

• services/svc-tenders/src/routes/registerKesRoutes.ts
• services/svc-tenders/src/kafka/kesEventConsumer.ts
• services/svc-tenders/src/kafka/kesDomainEventConsumer.ts
• services/svc-tenders/src/kafka/kesOutboxRelay.ts
• services/svc-tenders/src/kafka/kesDlqReplay.ts
• services/svc-tenders/src/kafka/kesOutboxPoisonReplay.ts

Classification verdict

Best current classification:

• VERIFIED
• REAL
• shared Kvary execution/backbone persistence hosted locally in svc-tenders

More precise wording:

• KES is not well-described as ordinary tender persistence
• KES is also not yet a fully separate shared execution platform in runtime ownership
• today it is a mixed transitional state

Why “mixed transitional state” is the honest label

Evidence against calling it purely tender-owned

• KES manages cases, process maps, tasks, inspections, payments, and orchestrator events
• this is broader than ordinary tender/procurement lifecycle storage
• it has explicit Kafka/outbox/runtime tooling

Evidence against calling it already shared-platform owned

• durable persistence is still implemented inside svc-tenders
• route registration is still hosted from svc-tenders
• no separate KES runtime service boundary exists yet

Practical interpretation

Today, KES persistence should be thought of as:

• real
• important
• event-driven
• hosted inside svc-tenders
• architecturally broader than tender domain
• not yet safely extracted

Recommended next step

Before extracting KES persistence, document:

• canonical KES write paths
• KES table ownership
• KES runtime/operator dependencies
• which parts are reusable execution-layer infrastructure vs KES-specific domain state