# Legacy database disposition — reconciliation, 2026-09-10

The [retirement record](legacy-retirement-260909.md) withdrew the proposed legacy database drop
"pending data-disposition reconciliation", and the [reuse protection register](legacy-reuse-protection-260909.md)
protects four databases. This note reconciles what can be reconciled from the repository and the
host without an owner ruling, and states exactly what an owner ruling still has to cover. Nothing
was dropped, restored, read or changed; the legacy database was not opened.

## Result in one table

| Database | Why protected | Live references today | Disposition |
|---|---|---|---|
| `gott_sibyla` | Production Main; "naming changes do not make these legacy assets" | Web, API, worker; `SyncConnectionGuard`, `ReleaseRunner`, design-time factories, run scripts, the deployment privilege gate | **Drop permanently declined.** It is production. |
| `gott_sibyla_preview` | Preview; same clause | Every database-backed test suite (`TestDatabase.cs`), the parity gate, `run-preview.ps1`, the Preview channel-intake role | **Drop permanently declined.** It is the test and parity infrastructure. |
| `gott_identity` | The live IdentityServer's database | `RegisterIdpClients`, the tenant seed's subject ids, sign-in for the whole platform | **Drop permanently declined.** It is not a legacy asset; it is the IdP. |
| `gott_sibyla_legacy` | "Retain pending an explicit data-disposition reconciliation" | **None** in `src\`, the deployment module or the Hermes plugins. Only guards and records: `Verify-LegacyRetirement.ps1` asserts it exists; the keep list names it; `AGENTS.md` repeats the rule | **Still withdrawn, not yet schedulable.** Three named conditions remain open (below). |

The "legacy database drop" is therefore reduced to one database, and even that one waits on the
owner. Three of the four names should never appear in a drop proposal again; this note is the
record that says so.

## What `gott_sibyla_legacy` is, and is not

- 16 MB, 109 tables, zero sessions (read-only host check). It holds the retired POC application's
  own state: FDR-shaped tables (`DOCLOG`, `FDCHDR`, `FDCDTL`, `DOCARC`, `BNKMOV`, …) and POC-only
  tables (`Documents`, `DocumentLines`, `FileAssets`, `ExtractionAttempt`, `ExtractionRevisions`,
  `ExcelCommits`, `AuditEvents`, `CodeLedger`, Cegid connections, purge and retention receipts).
- It is **not** the source of NP Group's 52 sync runs: those rows are in Main and their source is
  the FDR file tree `invoice-skill-build\Editor\Data`.
- It is **not** the source of the Argus answer keys: those were taken from `gott_sibyla`.
- It is **not** the handover import source: the 2026-09-05 re-amendment of D10 ("import all the
  documents in the handover, including bank") is about the FDR data the sync already carries, and
  it closes with "the operational restriction on `gott_sibyla_legacy` and `C:\SibylaApps` is
  unchanged". The 2026-09-02 ruling that the POC's own documents, edits and PDFs are not migrated
  is the one that speaks about this database, and the later note that "only the POC's edit
  history remains out of the carry-over" narrows it further. That is the contradiction the
  register refused to resolve on its own.
- Repository credentials cannot look inside it: `sibyla_migrator` can connect but has `SELECT` on
  none of the 109 tables (all owned by `gott`), and 99 tables were never analysed. The `gott`
  password survives only inside the restricted retirement archive. Any content audit goes through
  a restore of the dump, not the live database.

## Backups

| Artifact | Where | Size |
|---|---|---|
| `gott_sibyla_legacy.dump` (custom format, `--create`), `pg_restore --list` index, schema SQL, pre-state inventory | `D:\Backups\SibylaRetirement\20260909-120359\` | 591,272 bytes for the dump |
| `gott_sibyla_20260901T013111Z.dump` (independent earlier copy) | archived GitLab project `gott-sibyla-legacy`, commit `940ee49`, `backups/database/` | 579,693 bytes |

The dump was listed and fully decompressed to null on 2026-09-09 and its hash recorded. **A restore
rehearsal has never been performed** (`manifest.json` records `RestoreRehearsed = false`). The
archive is same-host recovery, not a bare-metal backup.

## The three conditions still open

1. **One owner ruling that reconciles the handover records.** The POC's own rows: carried over
   (which rows, into what), or declared out of scope for good. The FDR question is settled by
   D10's re-amendment and by the sync; only the POC-row question is open.
2. **A restore rehearsal** of `gott_sibyla_legacy.dump` into a throwaway database name, timed,
   with the row counts compared against `database-restore-list.txt`, then dropped. This is also the
   Phase 3 restore drill the status map still lists as open, and it is the only way to look at the
   data without the `gott` password.
3. **An answer to D-49**, the legal retention period per document category. The discovery notes
   assume PT fiscal retention of at least ten years and say the retention engine stays a stub until
   confirmed. A drop of a database holding fiscal documents cannot be scheduled while the retention
   obligation is an assumption, even with two dumps in hand.

And, procedurally: a fresh explicit authorization. Both prior authorizations carry
`grantsFutureExecutionApproval: false`, and any drop must be paired with edits to the keep list
and to `Verify-LegacyRetirement.ps1`, which would otherwise fail its postcheck.

## Recommended path

Do the rehearsal first (condition 2): it costs one sitting, produces the row-count evidence that
condition 1 needs, and closes a Phase 3 gate on its own. Then put conditions 1 and 3 to the owner
in a single ruling. Until then the disposition stays exactly as the register has it: retain.

## Decision requested

| Id | Question | Recommendation |
|---|---|---|
| Q-LDB-1 | Record the drop of `gott_sibyla`, `gott_sibyla_preview` and `gott_identity` as permanently declined? | Yes; add the wording to the keep list's rules so no future proposal lists them |
| Q-LDB-2 | Authorize the restore rehearsal of `gott_sibyla_legacy.dump` into a throwaway database (read-only afterwards, dropped at the end of the sitting)? | Yes |
| Q-LDB-3 | The POC's own rows: carry over, or out of scope for good? | Out of scope, consistent with the 2026-09-02 ruling and the "only the POC's edit history remains out" note, unless the rehearsal shows rows the FDR never had |
| Q-LDB-4 | D-49: confirm the retention period per document category | Owner's or the accountant's answer; ten years is the working assumption |

## Incidental finding

`local\secrets\db-backups\channels-20260908-194818\web-secrets.json` holds production connection
strings in clear text. The directory is git-ignored (`.gitignore` line 15, verified), so nothing is
committed; it is flagged here only so the owner knows the file exists on the host.