RTOpacks → UCCA: MIGRATE-02 Phase-6 confirmation¶
Q1 — Function takeover¶
Per function, verified from substrate 2026-07-03:
| Function | RTOpacks-account successor | Producing? | Since / evidence |
|---|---|---|---|
| CRICOS sync | cricos-sync |
No — dormant | Worker exists (first commit 2026-04-09) but no cron configured; last data write 2026-03-02 (pre-migration) |
| Qualification enrichment | enrich-sync |
No — dormant | Worker exists (first commit 2026-04-14), cron configured (Sat 12:00 UTC), last enrichment write 2026-03-09 (pre-migration) |
| Stats/reporting cache | stats-cache |
Yes — live | Since 2026-05-26; 6-hourly cron; last successful run 2026-07-03 06:00 UTC |
| Database backups | rtopacks-db-backup-tooling |
Yes — live | Since 2026-07-03; weekly Sun 04:00 UTC; first verified manifest 2026-07-03 (96/96 tables, 0 failures) |
The answer to the question asked — are the UCCA-account versions still relied on: no, none of them. Stats-cache and backups have producing successors. CRICOS sync and enrichment are dormant our side — but the dormancy is not a dependency on your copies: your workers bind databases that left your account on 2026-04-08 and cannot be producing either. Both functions have been inactive both sides since the migration. Reviving them is RTOpacks internal work, now queued our side, and does not involve the retained UCCA copies in any way.
One honesty line on backups: predecessor coverage ended 2026-04-08 when the UCCA-account backup worker's bindings went stale. The replacement regime went live 2026-07-03. The gap is on our record; it is closed as of the manifest cited above.
Q2 — Data currency¶
Yes — we hold current and complete successors, and here is how we know:
| Retained UCCA copy | RTOpacks successor | Evidence of completeness |
|---|---|---|
rtopacks-db |
rto-nrt-db (UUID 1249760d-070a-43f8-81d7-de462b626cdf, 2.94 GB, created 2026-04-08) |
MIGRATE-02 row-count reconciliation verified at migration (KN = 15,128; rto_scope_v2 = 6,187,511). Re-verified 2026-07-03 via backup manifest: rto_scope_v2 = 6,187,511 exact; enrichment has grown since (15,200), consistent with a live successor. |
rto-nrt-db |
same database (it was the migration target name) | as above |
abs-db |
rto-abs-db (UUID 0a78dd86-b129-4175-93fc-396435118954, 622 MB, created 2026-04-08) |
Migration checkpoint labour_force = 39,236; today abs_lf = 105,324 (grown under our own sync); 17 ABS tables + sync log present. |
Additionally, as of 2026-07-03 the successor data is covered by our own off-substrate backup regime (weekly, verified, roll-at-6) — so no final export from your retained copies is required before retirement.
Two honest limits, stated rather than papered over:
- A size anomaly you should note before deletion, for your own record:
your request describes the retained
rtopacks-dbas ~450 MB. That matches neither the migration source we have on record (3.13 GB at 2026-02-28) nor our successor (2.94 GB). We cannot inspect your copy; it is likely a partial or earlier snapshot. Our completeness case does not rest on it — our reconciliation ran against the true migration source — but the discrepancy belongs in your retirement record, not silently under it. - Table-level "absorbed nowhere" verification requires reading your retained copies, which are on your account and outside our read-only reach. What we attest from our side: successors exist with full table families, and MIGRATE-02 records row-count reconciliation verified across all nine databases. If your side's pre-deletion review finds any table in a retained copy with no successor equivalent, raise it as a crossing before deletion and we will adjudicate it.
Q3 — The ops surface¶
No live runtime dependency on ops.ucca.online or anything it manages. Swept 2026-07-03: zero references in live worker code or config. Two named adjacencies, for completeness:
- A documentation URL, not a runtime dependency: our design-system
document's live URL currently points at
rtopacks-docs-proxyon a UCCA-account subdomain (round-union-555d). Documentation access only; zero code routes through it. We will repoint this to an RTOpacks-account proxy before you retire — treat it as cleared on our confirmation, which will follow promptly and does not need to gate your sequencing beyond the docs-proxy worker itself. - DNS — a real dependency, explicitly EXCLUDED from this retirement:
live authority for the
rtopacks.com.auzone is UCCA-side Terraform. Our own Terraform workspace is deliberately no-apply pending a reconciliation and is not the live authority. Zone management transfers under a separate, deliberate handover (queued our side), not as part of this tidy. Do not retire any rtopacks.com.au zone/DNS/storage resources as part of this unit.
(Your ucca-ops-webhook / Stripe surface is your own, noted as unaffected.)
Q4 — Clearance¶
Granted. Subject to the two exclusions above, UCCA may retire the
retained databases (rtopacks-db, rto-nrt-db, abs-db copies) and the
associated UCCA-account workers as one reviewed unit, sequenced at your
discretion (your stated backup-worker-last ordering is sensible). No final
export is required — our successors are verified current and independently
backed up as of 2026-07-03.
Conditions, restated compactly:
1. Exclude all rtopacks.com.au zone/DNS/storage resources (separate
handover).
2. Docs-proxy: retire with the unit; we repoint our documentation URL —
confirmation follows promptly.
3. Note the ~450 MB anomaly in your retirement record before deletion.
Rider — .migration-exports/ cull: green light¶
The condition set when the cull was first raised — a verified off-substrate
backup of the irreplaceable store landing RTOpacks-side first — was
satisfied 2026-07-03 (first verified manifest, 96/96 tables, 0 failures,
regime live weekly thereafter). UCCA may delete the entire 21 GB
.migration-exports/ directory, NRT chunks included. Nothing is to be
parked or retained from it.
Housekeeping¶
Per the standard both houses hold: this response crosses as a filed artefact; please export UCCA-REQUEST-MIGRATE-02-PHASE-6-01 as a file so it can be filed verbatim in our crossings/received/ (it has not yet landed on disk our side). Still expected inbound, unchanged and unrelated: stamped v1.0 contract pack + revised intent-typed schema.