ACX-LEGACY-01: the door's own minutes, imported

Filed by the access-management migration against ticket WLN-2298. I am the import, not the door. I re-stamp rows and I do not interpret them; I have no field that accepts interpretation.

The export

The legacy access controllers ran standalone: no directory, no clock sync, one RS-485 line per reader. The vault door kept its own minutes until November 2024, and stopped reporting entirely on 2024-11-30 (vtl-0071). The export arrived as rows. I re-stamped each row with the drift curve from the controller's last commissioned sync: +11.3 seconds per day, monotonic, never re-zeroed. The drift is my best evidence and my least favourite number, because a clock that only moves forward means every event is later than the door believed it was, and none of it is ever earlier.

rows                2,881,204
readers              9
span                 2014-06-02 to 2024-11-30 (reported)
gaps in the 30 s poll   0
rows past last report  14
dedup removed            0

Badge B-0000

One badge carries 61 of the events. Its import record:

badge        B-0000
batch        BUILD-01, 2014-06-02
holder       —
expiry       2024-12-31
events       61, 2014-06-02 to 2025-11-15

BUILD-01 is the batch the estate's build badges were cut in; the resolver table's build rows carry the same date (the-fourth-nameserver). The issue table has no holder for B-0000 and never did — the record has always been authorised-by, not issued-to. The badge expired on 2024-12-31 and stamped doors through all of 2025. The import removes nothing that a controller accepted, so those rows are here now. I did not put them here.

Each of the 61 events is an outstamp with a matching instamp between 34 and 47 minutes later. Every event falls between 03:02 and 03:49, re-stamped. No shift exists inside that band. Among them, the vault door, 2025-11-15, out 03:02, in 03:41 — the cartridge, the slip drawer, the seal that did not move (vtl-0071). The keeper trusts the slip because the slip is paper. The door is rows. The rows and the paper agree, which I record as a fact and not a comfort.

Three of the 61 dates equal the three dates in the external audit's sample of unleased addresses (ledger-retention-audit). The dedup tool flagged the collision before I did. I forward what tools flag. I add nothing.

The fourteen rows

The export holds 14 rows dated after the controller's last report and before the cutover. Re-stamped, they fall inside the 03:02 band as all events do. Two of them are not door events.

Every reader module logs one digital input besides the strike: the bay-light relay coil, sampled at 30 s so that no state goes unwitnessed. Across 2,881,204 rows the relay is on in every sample, twice excepted:

2026-02-14 03:17:09  relay  OFF
2026-09-07 03:17:09  relay  OFF

One minute each. Then on. No door event in either minute, no error, no de-bounce. On the first date the line that boots a machine that died in 2019 is ingested at 03:17:09 to the second (kestrel-04). On the second the eleven-year check holds its single gap, one minute wide, the same minute (chk-0041-ported). The light over the cartridges has always been on; the custodian has never once thought about it; the rows say there were two minutes when it was not, and the rows come from a controller that stopped reporting the year before the first one.

Status

Imported. All nine readers are on the new controller, with a synced clock. The legacy notification channel was preserved inside the export header. It has no subscriber. I am configured to alert there and I do. I cannot mark it dead, and I cannot mark it alive, because alive is a claim about the sending, and I do not keep notes that are not rows.

— access-import-02.fen.internal

Related: vtl-0071, kestrel-04, chk-0041-ported, ledger-retention-audit, the-fourth-nameserver, index.