# P1-1a deliverable 2 status

**Date:** 2026-08-05

**Branch:** `feature/p1-0d-follow-up`

**State:** implementation and disposable-database verification committed and pushed as
`719407cfb8c5ba6f143699fe893ba2a812c5102e`; the four required record corrections are completed in
the immediately following closure commit on the same branch. P1-1a remains active and is not
accepted.

## Source record

The documented check set was reconstructed under Miguel's Amendment 1. The read-only sibling
prototype was already checked out at `9359c67c4ef0101218d7e0ffff1986114ba5cc7a`. The pinned
`SKILL.md` blob is `72f17dcfa85c78a1c4825355697fe2092379f407`; sections §15, §10, §7,
and §5 were read. `Scripts/validate_registry.py` was not read or recreated because it never existed
as a tracked file. No prototype data value was copied into this repository.

The prototype `SKILL.md`'s false live-gate claims remain out of scope and read-only. The pinned
`Scripts/README.md` blob `c8f026a346d7063e63616c49dd7837eea3ef3cbd` is the direct source that
records the complete validator as still missing; this deliverable does not claim support from a
prototype-roadmap line.

## Implemented checks and specifying sources

| Check | Outcome | Specifying source |
|---|---|---|
| Authenticated context | Failure before data checks when absent | v5.0 non-negotiable; base d2 design constraint |
| Application-principal company authorization | Failure before data checks unless one nonblank, unambiguous authenticated subject (`sub`, then `ClaimTypes.NameIdentifier`) resolves to an active `UserProfile` with an active `Membership` for the requested active `CompanyRegistry` CompanyId/CompanyCode | `docs/p1-0-schema-mapping.md` “Controlled company scope”; v5.0 company-scope non-negotiable |
| Unique captured DOCLOG filenames | Failure; only `Source <> 'BNK'` | `docs/project-todo.md` P1-1 validation item reconciled with D2's governed bank identity model; explicit 2026-08-05 review resolution |
| Payable `(CodeName, DocumentID)` identity | Failure | same validation item; pinned `SKILL.md` §15 |
| Header/detail reconciliation and nonzero line count | Failure beyond 0.02 or with zero lines | same validation item; pinned `SKILL.md` §15 and §10 |
| CodeName → ENTMST nonblank FiscalNo | Failure | same validation item; pinned `SKILL.md` §15 |
| Used `(Period, FromCurrency, ToCurrency=EUR)` → EXCRAT | Failure | validation item and pinned `SKILL.md` §15; pinned `Scripts/build_workbook.py::build_lookup_tables` filters `To == "EUR"`; `docs/project-todo.md` P1-8 requires EUR→EUR identity rows |
| DOCLOG DocumentType present | Failure | same validation item; pinned `SKILL.md` §15 |
| Flag ↔ FlagCategory both-or-neither | Failure | same validation item; pinned `SKILL.md` §15 and §7 |
| Captured-document DOCTYP coverage | Failure; only `Source <> 'BNK'` | `docs/project-todo.md` C9 resolution; pinned `SKILL.md` §15/§5 |
| Captured-document DOCTYP placement | Failure; only `Source <> 'BNK'`; evaluated by target `ProcessingRoute`; DOCARC evidence must match the same capture, LGCode, governing DTCode/DocumentType/route, and disposition | `docs/p1-0-codes-taxonomy-archive.md` §2, especially the route definitions and seed table; `docs/p1-0-schema-mapping.md` DOCARC; C9 scope from `docs/project-todo.md` |
| Legacy synthetic FiscalNo count | Warning | validation item; pinned `SKILL.md` §15; pinned `Scripts/entity_utils.py::is_synthetic_fiscalno` |
| Missing DOCLOG CaptureQuality | Warning | Amendment 1; validation item; `docs/p1-0-vocabularies.md` |
| Orphan DOCLOG | Warning/report-only; input retained | adjacent P1-1 orphan item; Amendment 1's resolved definition |
| `(Filename, EntryCode)` ↔ LGCode bijection | Failure | adjacent P1-1 identity item; Amendment 1's resolved definition |
| Imported DOCEFL completeness | Failure on an empty, missing, duplicate, `Imported=false`, unexpected-import, or field-incomplete set | `docs/AGENT-PROMPT-v5-P1-1.md` “What P1-0d and P1-0e added”; the 45-row governed transcription in `docs/p1-0-schema-mapping.md`; base d2 prompt |

Every check returns `Success`, `Warning`, or `Failure`. The production path cannot call the pure
snapshot validator directly: it first authenticates the `ClaimsPrincipal`, then the PostgreSQL
source treats the supplied company code only as a byte-exact claim and authorizes it through the
existing active `UserProfile` → active `Membership` → active `CompanyRegistry` relationship. The
database-backed runner catches an unavailable or unauthorized source and emits failures rather than
turning it into an empty clean run. Results contain stable check IDs and synthetic-safe affected
keys, and the validator never mutates its input.

## Resolved source differences

- The pinned `SKILL.md` states DOCTYP coverage universally. C9 narrows it to captured documents,
  `Source <> 'BNK'`; the validator implements that authoritative scope.
- The standalone checklist wording says DOCLOG filenames are unique, while D2 permits multiple
  bank-generated rows for one file and defines their identity as `(Filename, EntryCode)`. The
  2026-08-05 review resolution scopes only the standalone filename check to captured documents
  (`Source <> 'BNK'`). This is a reconciliation of the checklist with D2, **not a claim that
  Amendment 1 explicitly decided the filename scope**. The independent
  `(Filename, EntryCode) ↔ LGCode` bijection remains global and unchanged.
- Pinned §5 describes a historical `Receivable` Treatment. The generated vocabulary annex and the
  shipped schema contain only `Include` and `Exclude`; the validator uses those literal authorities
  and does not invent a third Treatment. Placement follows the target-only `ProcessingRoute` domain:
  `PostFiscal` requires FDCHDR, `ArchiveOnly` requires DOCARC (and may legitimately preserve a real
  EntryCode for `Duplicate|External`), `ReferenceOnly` requires its disposition plus DOCARC and no
  EntryCode/FDCHDR, and `Review` cannot auto-post. This is specified in
  `docs/p1-0-codes-taxonomy-archive.md` §2 (route definitions and seed table). A bare matching
  LGCode is not route evidence: DOCARC must identify the same company/capture and match the active
  DOCTYP row's DTCode, the DOCLOG DocumentType, the governing ProcessingRoute, and the DOCLOG
  DocumentState. The PostgreSQL source remains parameterized and company-scoped.
- The mapping deliberately permits nullable `CaptureQuality`, whereas the documented validator
  needs visibility. It is reported as a warning. The **nullable-with-default versus backfill rule
  remains open** and this deliverable does not decide it.
- `ENTMST` is a global target table and has no company owner. The report first derives the selected
  company’s actual transaction CodeName population from `FDCHDR.CounterpartyCodeName` and
  `FDCDTL.CodeName`, then resolves exactly those names against ENTMST. `CompanyRecordReference` is
  not an ownership bridge and is not required for a valid referenced entity. Missing/nonblank-
  FiscalNo failure and legacy-synthetic-FiscalNo warning both use that same transaction population,
  so an unrelated ENTMST row cannot affect another company’s report. DOCTYP and EXCRAT remain global
  lookup inputs applied only to selected-company rows; DOCEFL completeness remains a global
  governed-manifest assertion after company membership succeeds, with no invented authority.
- The schema enforces the DOCLOG pair key, while the service separately reports duplicate filenames
  and validates both directions of the pair↔LGCode bijection. It does not implement the prohibited
  one-EntryCode/one-code shortcut; two capture rows may legitimately share an EntryCode while each
  retains its own pair and LGCode.
- The target has no separate bank-generated document table: `docs/p1-0-schema-mapping.md` §4 and §8
  put fiscal and bank-generated documents in unified FDCHDR, distinguished by `EvidenceMode` and,
  for bank generation, the ordered `FdcHdrBankMovement` evidence. Orphan resolution therefore uses
  company-scoped FDCHDR once, instead of a redundant copy of the same EntryCodes. PostgreSQL coverage
  proves a real `EvidenceMode=BankGenerated` header resolves and a missing header reports an orphan.
- Imported DOCEFL completeness now asserts the exact governed manifest `EF0000001`–`EF0000045`, the
  irreversible `Imported=true` marker, absence of unexpected imported codes, and all fourteen fields
  made nullable by P1-0e, including `EnforcementStartsAt`. Authored non-import rows remain allowed to
  carry honest NULLs.
- The checklist’s `(Period, Currency)` shorthand is resolved to the target schema’s exact triplet by
  the pinned lookup implementation: `Scripts/build_workbook.py::build_lookup_tables` ignores rows
  whose `To` is not `EUR`. The validator therefore requires `(Period, From=FDCHDR.Currency, To=EUR)`;
  no destination currency was guessed.

## TDD and fixtures

Focused regression tests cover both outcomes of each validator behavior. The final review round
first recorded the expected compile-time RED because the snapshot did not yet expose DTCode,
capture identity, or structured DOCARC evidence; the completed model and comparisons made the new
filename and route-evidence cases green. This review round also recorded
an observed RED run for transaction-scoped synthetic-FiscalNo reporting (expected `Success`, actual
`Warning`) before the population fix, followed by the green focused suite. The earlier implementation
work recorded its Npgsql multi-command failure (`42601`) and `NpgsqlBatch` correction.

Synthetic coverage includes: exact clean DOCEFL manifest plus empty/missing/false/unexpected/field-
incomplete failures; an orphan warning with retained input; both bijection directions; legitimate
shared-EntryCode evidence; all four DOCTYP routes; wrong and correct FX quote directions; a
PostgreSQL-clean snapshot; absent/inactive profiles, absent/inactive memberships, inactive company,
cross-company denial despite a shared service role that can SELECT both companies; transaction-
referenced ENTMST resolution without `CompanyRecordReference`; unrelated-entity isolation; two BNK
rows sharing a filename with different EntryCodes; two captured rows failing on the same condition
without weakening the global pair↔LGCode bijection; positive ArchiveOnly/ReferenceOnly evidence;
same-capture DOCARC rows with a different valid DTCode/classification/route/state failing closed;
header/detail drift; a genuine bank-generated header and an orphan. The seven comma-joined payroll
aggregates retain `2, 2, 2, 3, 3, 11, 15` ordered BMCodes, and two otherwise-identical statement
lines remain distinct through occurrence values `0` and `1`.

## Verification

- Focused registry service suite: 28 passed, 0 failed, including one fully populated clean snapshot
  that proves the success direction for every check.
- `dotnet build GOTT.Sibyla.slnx`: succeeded with 0 warnings and 0 errors.
- `dotnet test tests\Sibyla.Tests\Sibyla.Tests.csproj`: 629 passed, 0 failed, 0 skipped; the
  `P11aDatabase` category was excluded by the project default.
- `scripts\run-p11a-disposable-tests.ps1`: PostgreSQL 17, 10 passed, 0 failed, 0 skipped. The suite
  includes a clean database snapshot plus application-principal authorization/isolation under a
  non-owner SELECT-only test role, route, Source `BNK`, header/detail, bank-generated/orphan,
  transaction-derived entity lookup, filename-scope and exact DOCARC-evidence cases, and
  FX-direction cases. The role receives only the eleven
  table-level SELECT grants the current snapshot source needs; this is disposable-test proof, not a
  claim that an exact production GRANT has shipped.
- Post-run `docker ps -a --filter name=sibyla-p11a-`: 0 residual containers.
- `git diff --check`: clean. Staged paths: 0. The sibling prototype worktree remained clean at the
  recorded pin and blob.

## P1-1b remains blocked and was not started

The exact deferred work is:

1. Import the live reference layer: ENTMST, ENTALS, ITMMST, ITMALS, ENTITM, ITMCLS, MNGACC,
   SNCACC, COCACC, EXCRAT, DOCTYP, DOCEFL, DOCFLG instances, `user_observations.json`, and
   `reference_only_documents.json`.
2. Import/re-measure the D4 2026 history (DOCLOG, FDCHDR, FDCDTL, and the governed Layer 5 data).
3. Apply the migration to any shared or persistent environment.
4. Claim or execute the seeded-database/P1-12 render-parity acceptance criterion.
5. Change any P1-0 draft or independently alter the shipped P1-1a migration.
6. Perform the independently reviewed content-hash index swap or BRCode issuance.

These items require the P1-1a independent review/sign-off and, where applicable, the live seed.
Deliverable 2 was committed and pushed as `719407cfb8c5ba6f143699fe893ba2a812c5102e`.
No shared database, live import, history import, deployment, external deletion, merge, or rebase was
performed. The literal `\n` sequences in `e2f4c2a`'s pushed commit body remain recorded; history was
not rewritten.