coulomb-social/docs/release/service-provenance-reconciliation-2026-10-30.md

Service source and attribution reconciliation

WP-0012-T03 remains open. This check corrects release-source evidence and identifies the missing client attribution join; it does not deploy or register anything, book cost, approve an identity mapping or finish service conformance.

Current image source

A read-only native deployment query still observes deployment UID 2dbe661a-d232-4477-bbd1-833813077fbe, one replica and image digest 9a646d8e01a61ba5316d3c2eb0273064e17f2d0300ad07af766ccedda65ecb18. The October 8 release receipt and current deployment-owner values name source dd83c90d73a1f7153581949424603e7b38eec014. The app release-unit declaration instead named 796a1557e9e5ff68800f9676d050d5b1efe7a138.

The retained digest image has no OCI revision label, so that label cannot prove either source claim. scripts/verify-packaged-source.py bypasses its entrypoint and hashes the entire packaged application plus manage.py, pyproject.toml and the renamed entrypoint. It compares those bytes with exact Git objects, without starting Django, mounting host files, pulling an image or contacting a database. The disposable container has no network and a read-only root.

All 69 packaged files match dd83c90 exactly. Commit 796a1557 has 70 source files and eight differing/missing packaged paths. The release-unit declaration now pins dd83c90, matching both the actual packaged source and owning release values. The image digest, production and prepared storage proposal are unchanged. This comparison proves source-byte equality, not dependency provenance or build reproducibility. It does not retag or rebuild the historical artifact.

Repeat using the locally retained immutable image:

python3 scripts/verify-packaged-source.py \
  --image forgejo.coulomb.social/coulomb/coulomb-social@sha256:9a646d8e01a61ba5316d3c2eb0273064e17f2d0300ad07af766ccedda65ecb18 \
  --source dd83c90d73a1f7153581949424603e7b38eec014 \
  --source 796a1557e9e5ff68800f9676d050d5b1efe7a138

This command reports each comparison; inspect all_packaged_source_bytes_match. It does not select or publish a source pin automatically.

Client attribution remains unresolved

The existing resource:tenant:coulomb:coulomb-social value is an authoritative resource-control inventory ID and that inventory's dedicated allocation key. It is not a fin-hub client attribution key. Running the actual fin-hub parser rejects it. Fin-hub's current contract requires the three externally authoritative dimensions and derives client:<id>|app:<id>|instance:<id>; resource/infrastructure IDs retain their separate namespace. Do not simply rename the resource ID.

The inspected sources establish different axes:

Axis	Evidence
Product/application	coulomb-social
Resource inventory tenant	tenant:coulomb
Resource financial consumer	entity:coulomb; procurer is entity:railiance
Deployment values' default tenant	tenant:coulomb
Retained accepted-cohort SQL selection	tenant:platform
Legal client baseline	The accepted business-app contract says Binky Hedgehog GmbH is client #1.

Those values do not establish a canonical client × app × instance mapping by themselves. A default tenant is not proof of every stored row's tenant, and a financial entity is not automatically a client ID. Keep the native data and all existing IDs unchanged. WP-0014's explicit source/tenant/grant reconciliation must preserve the accepted cohort's actual tenant rather than changing it to make a cost join pass.

Required return under the existing WP-0012-T03: an authoritative mapping for the client and instance, linked to the resource/deployment and actual tenant scope; then the same canonical key through finance ingestion and a per-instance report backed by actual costs/authoritative shared allocation. Missing amounts stay unknown. CPU requests, a synthetic CSV or a new alias cannot prove booked cost.

The local State Hub compatibility catalog returns 404 for the exact service slug and zero rows for repo_slug=coulomb-social. This proves only that local surface lacks the record. Ops-hub documents a hub-core-hosted owner surface and a separate attended bootstrap; these local observations do not prove absence there or authorize bootstrap. Its current typed compatibility schema also lacks a client instance relation. A prose description alone would not satisfy the service contract's complete client/environment/endpoint registration requirement.

The companion JSON retains bounded observations, source hashes and comparison counts. It contains no application bodies, credentials, provider costs or fabricated identity mapping. Ruff and whitespace checks pass; application behavior/tests are unchanged, so the existing 383-case full gate is not claimed as a newly executed acceptance result for this metadata correction.

Owner-surface follow-through, 2026-10-31

Read-only requests to the documented operations owner surface, https://hub.coulomb.social/api/v2/openapi.json and /api/v2/hubs, both failed certificate verification with CERTIFICATE_VERIFY_FAILED: self-signed certificate. No authenticated service-record response was obtained. Verification was not disabled and no bootstrap mutation was attempted. This is an access/evidence blocker, not proof that the service record is absent.

The finance source's default ledger is .fin-hub/ledger.db. Opened directly with SQLite mode=ro, the existing local file contains seven ledger entries and only the legacy entry/import/meta tables. Its ledger_entries schema has no client_id, application_id, app_instance_id or cost_attribution_key; there is no engagement-price table. The ledger path is also documented in the owner's 2026-07-08 dogfood evidence. No schema migration, write, invoice-body disclosure or inferred zero cost was performed. This legacy local file cannot establish current client attribution or production finance ingestion; it does not prove that a newer owner-held ledger is absent.

Required returns remain the authoritative current operations record and finance mapping/report described above. These observations do not satisfy service contract §§4–5 or authorize inventing the missing client/instance identities.

Private operations runtime verified, 2026-10-31

The public TLS failure has a documented ownership context: Core Hub is intentionally private pending NetKingdom platform-root access acceptance. rapp-core-hub/helm/core-hub/values.yaml disables Ingress, and RAPPCOREHUB-WP-0002-T05 explicitly requires HUB-WP-0012 before public exposure. Its instructions prohibit restoring Ingress just to satisfy the old public smoke. This is not an incidental certificate repair for this application.

Read-only native metadata confirms no Ingress in namespace core-hub and one Ready replica each for the legacy API, hub-core candidate and repository publisher. Following the deployment owner's existing private verification path, anonymous GETs inside the candidate's network namespace return health 200/ok, protected /api/v2/hubs 401, and both OpenAPI aliases 200. No credential was read and no policy, listener, catalog record or deployment was changed.

The advertised schema includes compatibility hub/manifest routes and generic registry/projection ports. It has no explicitly named service/client/environment/ instance routes. That observation does not establish absence of service records: they may be represented through generic ports, and no authenticated catalog read occurred. The ops-hub descriptor is a capability declaration, not this application's registered client/environment/endpoint evidence.

The concrete upstream acceptance records are HUB-WP-0012-T05 for extension composition/caller grants, HUB-WP-0012-T07 for public exposure and RAPPCOREHUB-WP-0002-T05 for release routing/stabilization. A separately admitted private catalog read could also supply evidence without public exposure; no such read is claimed here. Keep the application registration requirement under CSOC-WP-0012-T03 and consume the owner record when available.

The custodian's client-hub document is still a scoping model, with proposed client, engagement and app-instance entities. It supplies neither authoritative IDs for this deployment nor finance facts. Its Binky Hedgehog baseline cannot be converted into an invented client × app × instance key. The operations record/mapping and actual per-instance finance report remain required.

Native observations and source hashes: service-owner-boundary-2026-10-31.json and its .sources.txt companion.

October 31: successor and identity decision bindings resolved

CSOC-WP-0012-T14 records this completed evidence reconciliation. T11 retains the remaining service contract work. Technical decision 7b68c574-aa61-4517-bb31-1ecda554c3e8 links existing approvals; it grants no new runtime action or policy exception.

The contract's Gitea registry address is historical. Founder decisions 6bf3700e-f9fa-4e4e-ab11-2c4e0b10d4d3 (Forgejo hostname/exposure), 804c1d54-e63f-4d88-8d85-a095a7a9e956 (registry scope) and 0cc6f748-c5c0-4ff1-9722-f59e6cd03fa5 (migration) establish the intended successor. The active CoulombCore production-freeze canon identifies railiance01 Forgejo as the canonical forge/registry target. Archived owner RAIL-HO-WP-0005 records completed cutover and deliberate legacy read-only fallback; State Hub independently returns finished for that plan and done for its T12. The July2 decision's14-day window and July9 source's30-day window differ: neither is treated here as permission to delete legacy state or proof of subsequent teardown.

Fresh read-only observations at13:38:26Z confirm one Ready Coulomb deployment on image522bcd7f from forgejo.coulomb.social/coulomb/coulomb-social. Its UID, current release-unit and deployment-owner values match the retained revision19 return. The anonymous TLS-verified forge version endpoint returns200 and 11.0.3+gitea-1.22.0; that compatibility suffix does not make it the retired Gitea instance. The retained80-file source equality proof keeps its original scope; this observation does not rebuild the image or prove reproducible dependencies.

For identity, the missing governing link is the existing founder decision 8bbce691-a787-4140-9cd4-df06e8635a27: it explicitly approved the exact historical NetKingdom OIDC/PKCE client restoration and Coulomb app release. Link this recorded choice to ADR-0001's authentication specialization under contract§8.3. Requiring the same product authentication choice to be approved again would disregard that recorded approval. This does not assert that a§2.4 demand trigger occurred, that all ADR statements are implemented, or that every authorization/MFA behavior has been accepted. The later password-reset role grant remains separately unapproved.

Evidence: service-provenance-binding-2026-10-31.json retains selected decisions, source hashes, native metadata and explicit limits. These two provenance items are resolved. Authenticated ops registration, actual client/app/instance finance mapping and current report, current SLO attainment and stage-1 smoke reconciliation remain T11; no full service conformance is claimed.