svc-tenders Validation Surface Map
Purpose
This note documents the densest route-adjacent validation surfaces in svc-tenders after Cleanup Sprint 25:
Resolving locale, route permissions, and workspace projection.
Current scope: Guest
Category: 10_normative | Version: v1.0.0
Owner: DOCUMENT_CUSTODIAN | Review cycle: 90 days
Approval authority: GOVERNANCE_ADMIN
Documentation portal is read-only. Editing and mutation endpoints are disabled.
Kvary platform is originally created in Georgian. Where a Georgian version exists, Georgian is authoritative for platform UI, documentation, and legal interpretation.
Translations into other languages are provided for convenience. Some records may originate in other languages and carry their own source or legal locale for a specific flow, but where a Georgian version is available, the Georgian version prevails for platform-level wording and interpretation.
Metadata incomplete: Document ID, Version, Status, Owner Role, Last Review Date, Next Review Date, Change Log
svc-tenders Validation Surface MapThis note documents the densest route-adjacent validation surfaces in svc-tenders after Cleanup Sprint 25:
The goal is validation literacy:
Labels used here:
VERIFIEDREALTRANSITIONALregisterTenderDeclarationRoutes.tsRoute module:
Support dependencies:
Purpose:
Type:
Checks:
tenderId)support.canCheckTenderDeclaration(...)Broader vs stricter:
Purpose:
Type:
Checks:
createTenderDeclarationDraftSchemaupdateTenderDeclarationDraftSchemasupport.hasTenderDeclarationCapability(..., "tender:create-draft")normalizeTenderDeclarationFormData(...)buildTenderDeclarationValidationResult(...)buildTenderDeclarationPreviewResult(...)Support helpers involved:
Purpose:
Type:
Checks:
checkTenderDeclarationReadinessSchemacanCheckTenderDeclaration(...)markTenderDeclarationReadySchematender:mark-readycanMarkTenderReady(...)declareTenderSchematender:declaredeclareTenderCommandSchemacanDeclareTender(...)Broader vs stricter:
Purpose:
Type:
Checks:
DRAFTsupport.parseTenderDeclarationEvidenceGroupKey(...)Support helpers involved:
runMulterSingle(...)parseTenderDeclarationEvidenceGroupKey(...)parseOptionalString(...)Notes:
DRAFT state gateregisterAuctionDeclarationRoutes.tsRoute module:
Support dependencies:
Transitional note:
Purpose:
Type:
Checks:
createOutputAllocationSchemaupdateOutputAllocationSchemacanCheckAuctionDeclaration(...)hasAuctionDeclarationCapability(..., "auction:create-draft")normalizeOutputAllocationFormData(...)Broader vs stricter:
Purpose:
Type:
Checks:
canCheckAuctionDeclaration(...)auction:create-draftSupport helpers involved:
Purpose:
Type:
Checks:
checkAuctionDeclarationReadinessSchemamarkAuctionDeclarationReadySchemaauction:mark-readycanMarkReady(...)declareAuctionAnnouncementSchemaauction:declaredeclareAuctionCommandSchemacanDeclareAuction(...)Broader vs stricter:
Purpose:
Type:
Checks:
auction:create-draft mutation gateDRAFTsupport.parseAuctionDeclarationEvidenceGroupKey(...)Notes:
registerKesRoutes.tsRoute module:
Support dependencies:
Transitional note:
Purpose:
Type:
Checks:
parseOptionalString(...)requireServiceAuthcreateKesOrchestratorCaseSchemaapproveKesOrchestratorLandownerSchemapublishKesOrchestratorAuctionSchemaconfirmKesOrchestratorFundingSchemaassignKesOrchestratorTaskSchemasubmitKesOrchestratorInspectionSchemacloseKesOrchestratorCaseSchemaNotes:
Purpose:
Type:
Checks:
Support helpers involved:
kesRouteSupport.tsparseKesOrchestratorListOptions(...)parseKesRole(...)parseKesCaseState(...)Purpose:
Type:
Checks:
upsertKesOrchestratorProcessMapSchemaNotes:
Purpose:
Type:
Checks:
requestKesOrchestratorPaymentSchemasupport.ensureThirdPartyKycBoundary(...)support.verifyIncomingSignatureGate(...)approveKesOrchestratorPaymentSchemasupport.verifyIncomingSignatureGate(...)settleKesOrchestratorPaymentSchemasupport.verifyIncomingSignatureGate(...)Broader vs stricter:
VERIFIED
These validation surfaces are not symmetric, and that is correct:
Trying to flatten these into one generic validation story would hide the real topology.