ICPI Happy-Path Write Verification
Auth Method Used
Happy-path ICPI write verification used the existing local dev impersonation flow already present in the repo.
Procedure used:
- start
svc-authwithDEV_AUTH_TOOLS=true - start
services/apiwithDEV_AUTH_TOOLS=true - call
POST /api/v1/auth/dev/impersonate - request body:
{
"email": "kvaratskhelia.ge@gmail.com"
}
- extract
tokens.accessTokenfrom the response - use that bearer token for
POST /icpi/upsertagainst direct hosts and gateway paths
This relied on an existing seeded dev identity already referenced by the web dev sign-in flow. No auth shortcut or auth model change was added.
Verification Item
Stable item used for the verification sequence:
itemCode:ICPI_S51_MMUN7BQ7sourceKey:SPR51- base row:
{
"year": 2026,
"quarter": 1,
"regionCode": "GE",
"categoryCode": "CEMENT",
"itemCode": "ICPI_S51_MMUN7BQ7",
"itemName": "Sprint 51 Parity Cement",
"unit": "kg",
"currency": "GEL"
}
Different sourceVersion and unitPrice values were used per stage so each successful write also had a clear persisted read-back.
Request Variants Used
Direct host parity payload
{
"sourceKey": "SPR51",
"sourceVersion": "s51-direct-hosts",
"rows": [
{
"year": 2026,
"quarter": 1,
"regionCode": "GE",
"categoryCode": "CEMENT",
"itemCode": "ICPI_S51_MMUN7BQ7",
"itemName": "Sprint 51 Parity Cement",
"unit": "kg",
"currency": "GEL",
"unitPrice": 101.11
}
]
}
Gateway fallback payload
{
"sourceKey": "SPR51",
"sourceVersion": "s51-gateway-fallback",
"rows": [
{
"year": 2026,
"quarter": 1,
"regionCode": "GE",
"categoryCode": "CEMENT",
"itemCode": "ICPI_S51_MMUN7BQ7",
"itemName": "Sprint 51 Parity Cement",
"unit": "kg",
"currency": "GEL",
"unitPrice": 102.22
}
]
}
Gateway cutover payload
{
"sourceKey": "SPR51",
"sourceVersion": "s51-gateway-cutover",
"rows": [
{
"year": 2026,
"quarter": 1,
"regionCode": "GE",
"categoryCode": "CEMENT",
"itemCode": "ICPI_S51_MMUN7BQ7",
"itemName": "Sprint 51 Parity Cement",
"unit": "kg",
"currency": "GEL",
"unitPrice": 103.33
}
]
}
Rollback confidence payload
{
"sourceKey": "SPR51",
"sourceVersion": "s51-rollback-fallback",
"rows": [
{
"year": 2026,
"quarter": 1,
"regionCode": "GE",
"categoryCode": "CEMENT",
"itemCode": "ICPI_S51_MMUN7BQ7",
"itemName": "Sprint 51 Parity Cement",
"unit": "kg",
"currency": "GEL",
"unitPrice": 104.44
}
]
}
Results
Old colocated host
Target:
POST http://127.0.0.1:4020/icpi/upsert
Result:
- auth succeeded
- status:
200 - response:
{
"ok": true,
"upserted": 1,
"meta": {
"received": 1,
"accepted": 1,
"duplicatesDropped": 0,
"sourceKey": "SPR51",
"sourceVersion": "s51-direct-hosts"
}
}
Read-back:
GET /icpi/latest/ICPI_S51_MMUN7BQ7?region=GE- business fields matched the written row, including
sourceVersionandunitPrice
New svc-icpi host
Target:
POST http://127.0.0.1:4021/icpi/upsert
Result:
- auth succeeded
- status:
200 - response matched old host exactly for the direct-host payload
Read-back:
GET /icpi/latest/ICPI_S51_MMUN7BQ7?region=GE- normalized business fields matched old host exactly
- timestamp fields were intentionally ignored in the parity comparison because
updatedAtlegitimately changes across successive writes
Gateway fallback mode
Gateway env:
TENDERS_SERVICE_URL=http://127.0.0.1:4020ICPI_SERVICE_URLunset
Target:
POST http://127.0.0.1:4001/api/v1/icpi/upsert
Result:
- auth succeeded
- status:
200 - response matched direct old host exactly for the fallback payload
Read-back:
GET /api/v1/icpi/latest/ICPI_S51_MMUN7BQ7?region=GE- normalized business fields matched direct old host exactly
Gateway cutover mode
Gateway env:
TENDERS_SERVICE_URL=http://127.0.0.1:4020ICPI_SERVICE_URL=http://127.0.0.1:4021
Target:
POST http://127.0.0.1:4001/api/v1/icpi/upsert
Result:
- auth succeeded
- status:
200 - response matched direct new host exactly for the cutover payload
Read-back:
GET /api/v1/icpi/latest/ICPI_S51_MMUN7BQ7?region=GE- normalized business fields matched direct new host exactly
Parity Verdict
Verified:
- successful authenticated upsert on old colocated host
- successful authenticated upsert on new
svc-icpi - successful authenticated upsert through gateway fallback mode
- successful authenticated upsert through gateway cutover mode
- persisted read-back parity after each stage
- rollback-stage successful write parity after gateway was returned to fallback mode
Verdict:
- happy-path authenticated ICPI write parity is confirmed for the checked seeded operator identity and request family
Notes
- Write-response parity was compared exactly.
- Read-back parity was compared on normalized business fields, excluding
createdAtandupdatedAt. - This verification proves a successful bearer-token plus principal-resolution path, not just denial parity.