Skip to content

Recon report — liveness, control panel, worlds

Top-line + contradictions with the filed record: the engine is ONLINE. Two clarifications to the filed record, neither a failure: (1) UCCA-TM-2026-07-03-TECH §3 lists only the spine — the account holds 18 Workers + 6 Pages projects total; the non-spine ones are UCCA's wider platform (fine) plus RTOpacks residue (below). (2) The retirement brief §A's "docs-proxy" item needs a guardrail: UCCA's own docs-proxy + knowledge-proxy are live UCCA infra — do NOT retire; the residue ones are rtopacks-docs-proxy / rtopacks-proxy (config-only, not deployed).

Unit A — engine liveness: ONLINE

Check Read Result
Gate health GET ucca-gate…/_health HTTP 200 {"status":"ok","surface":"gate"}
Proof job GET /v1/jobs/0dda7509… completed, envelope present, seal present
D1 job row SELECT … FROM jobs WHERE job_id=0dda7509 on ucca-input-path completed, envelope_ref=default/envelopes/0dda7509….json
R2 envelope envelope_ref resolved + object pulled earlier this session exists under /envelopes/
Workers deployed wrangler deployments gate + reasoner deployed 2026-07-03; keys deployed today (worker created 2026-03-17)
keys reachable GET keys.ucca.online/v1/public-key HTTP 403 = CF managed challenge on the public zone; the worker is up and the spine reaches it via the service binding (not the public route)

Verdict: ONLINE. The strongest evidence is functional: the proof job is completed with a sealed envelope, which required all three Workers + D1 + R2 + Queue to work together. Version-ID drift from the filed values wasn't cleanly extractable via CLI (deployments list showed timestamps, not IDs) — the deploy dates match today, no drift indicated. No new test job submitted (would burn GLM neurons; content quality is a separate lane).

Unit B — the control panel: ucca-ops (ops.ucca.online)

  • Served by the ucca-ops Worker (ops-v2, Next.js on OpenNext), deployed 2026-03-31. ops.ucca.online returns HTTP 403 + cf-mitigated: challenge (Access/challenge-gated; not read past the gate, as ordered). The permissions-policy header confirms an OpenNext surface behind it.
  • The world UI/API lives in the ops-v2 repo: app/w/catalog/worlds/page.tsx, app/api/worlds/…, lib/worlds/rtopacks/api/*. It is a control-panel surface, NOT part of the live engine spine — it talks to world data via its own DB/API, never through the gate.
  • Full account surface (flagging non-spine): Workers (18) — spine: ucca-gate, ucca-reasoner, ucca-keys (all 2026-07-03). UCCA platform: ucca-api, ucca-ir, ucca-mcp, ucca-site, ucca-time, ucca-track, ucca-vcc, ucca-corporate, reg-intel, docs-proxy, knowledge-proxy, drive-proxy, ucca-ops (the panel), ucca-backup (live infra). Residue: ucca-backup-large (SUSPENDED). Pages (6): ucca-knowledge, ucca-docs, ucca-trust, ucca-corporate (UCCA); rtopacks-docs, rtopacks-trust (RTOpacks residue).

Unit C — worlds inventory

The control panel populates exactly ONE world. lib/auth/seed.sql seeds account_worlds with a single row: world_id='rtopacks' (full). resolve-auth.ts defaults worlds: ["rtopacks"]. The account_worlds table (schema.sql) is a real access model, but only rtopacks has data or API code. The "two more worlds" are engine-repo concepts, not rendered in the panel.

World Where it appears Code? Data? Live-spine contact?
rtopacks (VET — primary) engine worlds/rtopacks/ (config); ops-v2 lib/worlds/rtopacks/api/*; account_worlds seed Yes (config + ops API) Yes (panel access row; corpus now in f95d4537) No — deployed reasoner excludes worlds/; ops-v2 reaches it via DB/API, not the engine
usa_for_later (≈ "US education" — Tim's 2nd) engine worlds/usa_for_later/ (marketing.py, ucca_config.py) Parked fossil (US contextualisation / Home Health Aide, LearnWorlds pivot) No No
moodle (the 3rd — but NOT a domain world) engine worlds/moodle/ Yes — but its README: "Moodle delivery connector — pushes UCCA capability objects to Moodle as SCORM 1.2 packages." No No — a backplane output connector mis-filed under worlds/

Tim's open recall — the third world: it is moodle, but the honest reading is that it is a delivery connector, not a domain world. Only two real domain-world concepts ever existed (rtopacks + US education); there is no defence/healthcare/aviation/etc. world in code. (worlds/ also holds output/ — generated artefacts, not a world.)

Drift-checks (both applied): no world-shaped structure touches the live spine's contracts. The deployed reasoner container ships only engine/generator/reasoner (no worlds/); the gate, the v1 schema, and D1 ucca-input-path have no world concept. The ops-v2 "worlds" are a separate control-panel surface. Verified by the container Dockerfile + the schema + the gate code — not assumed.

Unit D — RTOpacks residue cross-check vs §A

§A item Live state (read) Note
stats-cache, cricos-sync Not in the 18 deployed Workers config-only / not deployed — §A accurate
qual-enrichment Not deployed released by CORRECTION-02 — §A accurate
docs-proxy Ambiguous — GUARDRAIL: UCCA's docs-proxy+knowledge-proxy are live UCCA infra (do NOT retire); the residue is rtopacks-docs-proxy/rtopacks-proxy (repo dirs exist, not deployed) §A should name the RTOpacks proxies explicitly
ops-v2 / ucca-ops Deployed (2026-03-31), CUT ruled §A accurate
trust.rtopacks.com.au / rtopacks-trust.pages.dev Confirmed — Pages project rtopacks-trust present §A/C-5 accurate — coordinate with client
NEW — not in §A: rtopacks-docs Pages project present (rtopacks-docs.pages.dev, ~2 months) RTOpacks residue Pages project — add to the inventory
NEW — not in §A: ucca-backup-large Worker deployed but SUSPENDED 2026-04-09 (UCCA-CLEANUP-01) — "All RTOpacks DB exports removed … Cron disabled. No databases in scope." already inert; a deploy-surface cleanup, harmless

§A staleness verdict: substantially accurate; two additions (rtopacks-docs Pages, ucca-backup-large suspended Worker) and one guardrail (name the RTOpacks proxies, not UCCA's own). Corroboration for the forensic: ucca-backup-large's own config records a prior UCCA-CLEANUP-01 on 2026-04-09 that removed the cross-account RTOpacks DB export pattern — consistent with "the DBs left at the 2026-04-08 migration; no later mystery deletion."

HEADs

ucca-engine 7d25214 · ucca-docs (this commit). Account e5a98302 throughout; f95d4537 untouched; nothing deployed, deleted, or changed.