# Sibyla — Invoice Skill Build reconciliation matrix (S2-15 phase 1)

**Backlog item:** `docs/project-todo-v6.md` S2-15 · rev. 1, 2026-08-20 · **Scope of this
document:** the phase-1 traceability matrix and its recorded dispositions. The later phases —
the instruction bump from `sibyla-documental/2.3`, contract/validator changes only if genuinely
required, the golden-set harness, and target-host deployment — are separate merge requests per
V6-O1 and are **not** claimed here.
No confidential field values (amounts, invoice numbers, counterparty names, tax ids, accounts) are transcribed anywhere in this document; all prototype rules are paraphrased with file/section references only.

## Pinned state

- Reconciliation source pin: commit `395f433f2ff793fcc1260f9254cf1cfe10b4f096` ("Complete Stage 10 and Stage 11 registry updates", 2026-08-18T11:58:20+01:00, origin/main tip), read via git plumbing without checkout.
- The backlog's earlier observation (tip `3dd4150`, five commits ahead of `9359c67`, uncommitted SKILL.md revisions) is **superseded**: history is linear `9359c67 → 6146004 → 06825b5 → b917685 → 1e841a4 → 3dd4150 → 395f433`, and the prototype working tree is now CLEAN (no uncommitted revisions) on a local branch `s2-15-fase-1` at `b917685` — a branch observed already present before this matrix work began; nothing in this work created, moved, or checked out anything in the prototype. The pinned commit `395f433` — not the working tree and not `3dd4150` — is what this matrix reconciles against.
- Production baseline: extraction contract `sibyla.extraction.v3.1`, instructions `sibyla-documental/2.3`, which reference the prototype at `9359c67` (2026-08-04).
- Prototype repo is READ-ONLY; nothing in it was modified, checked out, or written during this work.

## Method

Rule enumeration:

1. `git -C D:/fileStorage/repos/invoice-skill-build diff 9359c67 395f433 --stat -- '*.md'` — 62 markdown files changed (the complete list is reconciled file-by-file in the Completeness Check section at the end).
2. Full-content diffs read for the canonical rule carriers: `SKILL.md` (root; `Specs/Skill/SKILL.md` is its byte-synced deploy copy), `Specs/Engagement Rules/Financial Document Capture Policy.md`, `Document Entry Line Classification Policy.md`, `Entity Entry Flow Procedure.md`, `Document Archiving Policy.md`, `Bank Movement Reconciliation Procedure.md`, `Specs/computed-fields.md`, `Specs/Lessons/lessons-learned.md`, `Specs/Lessons/known-limitations.md`.
3. Full text read at `395f433` for the four NEW rule documents: `Specs/Engagement Rules/Accounting Conformance Rule.md`, `Data Calculated Procedure.md`, `Inferred Values Procedure.md`, `Inferred Classifications Procedure.md`.
4. Block-entry notes read at `395f433`: `_to_delete/blockI_260808/_blockI_entry.md`, `_blockJ_entry.md`, `_blockL_entry.md`; Stage 10 R8 and Stage 11 R1–R7 change-log entries skimmed at heading level (`Specs/Change Log/_S10R8_entry_to_append.md`, `_applied/_S11R1..R6R7`).
5. Transfer copies compared: `_to_delete/s10r08_transfer_zips/_fresh_skill_260806.md` (702 lines) diffed against final `SKILL.md` (850 lines) — it is an earlier intermediate snapshot fully subsumed by the final file; no unique rules. Same for `_fresh_ll_260806.md` vs `Specs/Lessons/lessons-learned.md`.
6. Production cross-check read: `D:\fileStorage\repos\GOTT.Sibyla\docs\hermes-documental-agent-instructions.md` (sibyla-documental/2.3 + v3.1 contract), `docs\golden-documents.md` (§Next coverage list, including the S2-15 scenario block added 2026-08-19), `src\Sibyla.Infrastructure\Documents\ExtractionResponseValidator.cs`, `src\Sibyla.Infrastructure\Documents\DocumentValidationService.cs` (deterministic gates: known_direction, known_internal_company, known_counterparty, fiscal_number_present, NIF check, plausible_dates, currency_present, header_total, line_total), `src\Sibyla.Domain\Documents\ExtractionContracts.cs`.

Dispositions (exactly one per row):
(1) agent instruction · (2) extraction contract / deterministic validator · (3) cataloging or classification code · (4) golden-set scenario · (5) prototype-only / out of scope · (6) already covered — no change (by 2.3/v3.1/existing production code). A secondary golden-set note may accompany any disposition.

## Matrix

Prototype file paths are relative to the prototype root at commit `395f433`. "ACR" = `Specs/Engagement Rules/Accounting Conformance Rule.md`; "IV" = `Inferred Values Procedure.md`; "IC" = `Inferred Classifications Procedure.md`; "FDCP" = `Financial Document Capture Policy.md`.

### A. Reading and legibility

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-01 | SKILL.md §16 binding-verifier notes; lessons-learned S10R9 entries (commits 1e841a4–395f433) | An absent text layer proves nothing about readability; a visual read is required before any unreadability conclusion, and "no text layer" is counted as its own verdict, never folded into pass or fail. | (6) already covered | 2.3 "Reading modes and legibility" 1–3, warning taxonomy, acceptance checklist item 8; §Next already lists textless-legible and unreadable-after-fallback scenarios. |
| R-02 | `_to_delete/blockL_260808/_blockL_entry.md`; lessons-learned S10R9 (395f433) | Amounts printed in locale formats (spaces as thousands separators, comma decimals) must still be read correctly; when two candidate documents look alike, disambiguate by the document's own printed number, not by resemblance. | (1) agent instruction | 2.3 rule 5 covers output normalization but gives no reading guidance for spaced-thousands print formats, which the prototype demonstrably missed once on a first sweep. Secondary golden-set note: scenario G-a below. |
| R-03 | SKILL.md §16 "archive filename is a label, not an identity" (S10R9, roadmap 164/165); lessons-learned "a binding verified by name was never verified" | A document is identified by its printed content, never by the name it is stored or delivered under; storage naming conventions are not injective and a right-looking name can sit on the wrong document. | (6) already covered | 2.3 Input rules: filenames/paths/ids are orchestration metadata; "Filename similarity is never evidence". §Next already carries the duplicate-by-content scenario. |
| R-04 | SKILL.md §16 `verify_document_binding` block (S10R9, roadmap 165/167) | Content-binding check: the identifier a record claims for a document must actually appear in the document's extracted text, compared alphanumerics-normalized WITH a digit-boundary requirement (containment alone confirms false prefixes); "no text" is a separate verdict; the check must also run in reverse (stored files no record claims). | (2) validator | Mechanically enforceable post-extraction: v3.1 preserves printed document numbers verbatim (2.3 rule 3), which is exactly what enables a deterministic stored-number-vs-extracted-text binding gate. Not present in DocumentValidationService today. Secondary golden-set note: scenario G-f. |

### B. Document identity, duplicates, type

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-05 | FDCP §5 correction C-03 (S10R7, commit 06825b5 era; in 395f433) | A duplicate is a recognized outcome, never a capture failure; it has distinct routes (confirmed duplicate logged and archived; byte-identical stray discarded without a record; same-identity-different-amount pair is a CONFLICT requiring a human). | (3) cataloging code | Duplicate routing decides DOCLOG/DOCTYP treatment and touches prior documents. Production already has original-hash uniqueness (F1OriginalHashUniqueness migration) for the byte-identical case; the same-identity-different-content conflict tier is not evidently modeled. §Next near-duplicate scenario exists. |
| R-06 | `_blockJ_entry.md` (Issues #12/#13, S10R9) | Never remove the last copy: before discarding an incoming file as a duplicate, prove that the surviving record's evidence file actually resolves — identity match alone is insufficient, because the arriving file may be the only real evidence behind a placeholder entry. | (3) cataloging code | A deterministic invariant over document storage + prior documents; belongs beside Sibyla's immutable original store, not in the stateless agent. |
| R-07 | lessons-learned "check the currency before calling it a conflict" (S10R7) | Any amount-discrepancy or duplicate-conflict comparison must compare denominations first; two amounts in different currencies are not a conflict. | (2) validator | Mechanically enforceable; v3.1 extracts `currency` and `currency_present` gate exists, but no production comparison rule is currency-aware by evidence. Phase-2 note: if the duplicate-conflict comparison itself lands in cataloging (R-05), this currency-first guard lands there with it — the disposition names what enables the check (the contract's currency field), not necessarily its final home. Secondary golden-set note: scenario G-g. |
| R-08 | IC §8; FDCP §2 crosswalk C-08 (S10R7/S10R9) | Unrecognized is a valid answer: a document matching no type rule stays blank/unknown and routes to review; it is never assigned the nearest-looking type, and no catch-all type exists. | (6) already covered | 2.3 rules 6 and 12 (`unknown`, no invented category), status `needs_attention`; confidence rule 14 forces null confidence on `unknown`. |
| R-09 | FDCP §3 correction C-07 (S10R7) | "Rejected" means only a document type that never creates a financial record; an unreadable-but-untyped document is review-required, and an unprocessable one is a failure-route item — neither is "rejected". | (6) already covered | 2.3 status vocabulary separates `unsupported` (wrong kind of document) from `needs_attention` (incomplete) and `error` (unreadable after fallback), matching the corrected semantics. |
| R-10 | FDCP "Company assertion at capture" (S10R8, roadmap 102); SKILL.md §7/§18 `capture_company_gate` | Shared-inbox documents carry no company dimension; before booking, assert the document's own printed fiscal identity (bill-to for external, issuer for internal) against the booking company's master fiscal id. Mismatch = do not capture: blocking flag, no financial record, route to review. Absent printed identity may proceed, flagged. | (3) cataloging code | The comparison requires ENTMST/company-scope data the agent must never see; agent-side halves are already in 2.3 (independent buyer/supplier extraction, no company inference from path). Secondary golden-set note: §Next billed-to mismatch exists; scenario G-d adds the absent-identity variant. |
| R-11 | SKILL.md §18 `Inputs/` intake convention (S10R7) | Determine each document's company from its own content, never from the folder or filename it arrived under. | (6) already covered | 2.3 Input rules prohibit inferring identity/company from filenames and paths; extraction hint rules prevent hint-over-evidence override. Enforcement half is R-10. |

### C. Amounts, dates, periods

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-12 | ACR §2 rule R1 (new file, S10R9); computed-fields.md AccountPeriod rewrite | Stated-service-period reading: recognize a billing period printed on the document (coverage ranges, numbered-instalment phrasing, consolidated statements naming several months, stay or traffic periods); advance billing (period starts after issue date) means the FIRST month of the range, arrears means the LAST; evaluated per document, never per provider. | (1) agent instruction | v3.1 has `periodStart`/`periodEnd` header fields but 2.3 gives no reading guidance for these recurring Portuguese-market period-phrasing patterns; safe for a stateless proposal-only reader (evidence transcription + interpretation of visible text). The advance/arrears BOOKING decision itself is cataloging (R-13). Secondary golden-set notes: scenarios G-b, G-c. |
| R-13 | ACR §2 rules R2–R4, §4 stamp obligation, §5 conformance control (S10R9) | Booking-period ladder below the stated period: a per-entity recorded billing rule on the entity master (blank = default), then a documented day-of-month default, then a per-row review ruling; every divergence from the default must carry an appended, never rewritten, evidence stamp; a standing control reports undocumented divergences (must be zero), out-of-scope rows, and documented divergences (a falling count means stamps are being lost). | (3) cataloging code | Reads/writes ENTMST-style per-entity rules and prior documents — forbidden territory for the agent. |
| R-14 | ACR §2/§6 (S10R9) | Credit notes, reversals and corrections take the accounting period of the document they reverse, never their own issue month. | (3) cataloging code | Requires resolving the referenced prior document. Secondary golden-set note: §Next has a credit-note scenario; scenario G-e refines it (visible reference to the reversed document must be extracted). |
| R-15 | ACR §6; IV §5 (S10R9) | A period — or any value — is never assigned from nothing: an unusable date yields a blank field and a flagged row, not a guess. | (3) cataloging code | Extraction half already covered (2.3 rules 2/4: null + warning, ambiguous date to `additionalData`); the booking half (blank period propagation) is worker/cataloging. |
| R-16 | ACR §6 (S10R9) | The booking period is independent of the payment date; a settlement date never moves a period. | (3) cataloging code | Pure booking logic over reconciliation data the agent never sees. |
| R-17 | SKILL.md §18 "Evidence and Logic Control" (roadmap 112, S10R9); IV §6 | Deterministic plausibility screens over every posted row: settlement far before the document existed, due date before issue date, far-future document dates, booking period far from document date, and total ≠ net + tax — emitted as review signals with row lists, NOT hard failures, because legitimate prepayments exist. | (2) validator | Production already gates `plausible_dates`, `header_total`, `line_total` (DocumentValidationService.cs); the settlement-vs-document and period-drift screens are candidate additions on the worker side. Caution: the prototype's specific day/month thresholds were calibrated on the confidential corpus — re-derive rather than copy. |

### D. Evidence discipline and inference

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-18 | IV §2; IC §2 (new files, S10R9); SKILL.md §12 summary | Evidence-tier precedence: source-stated > linked-evidence > rule-assumed > pattern-inferred, and a lower tier never overwrites a higher one. | (3) cataloging code | Governs how the worker/cataloging layer merges extracted values with inferred ones; the agent only ever produces the top tier. |
| R-19 | IV §5 (S10R9) | Blank beats a guess: where no evidence supports a value, the honest state is empty, because a wrong value that looks right never asks to be corrected. | (6) already covered | 2.3 extraction rules 2 and 4 (never fabricate; null + warning), rule 9 (`ZZ`/`UNKNOWN`, never guess a country or id type). |
| R-20 | IV §3 (S10R9) | Every rule-assumed or pattern-inferred value must carry an audit note on the row naming the rule that fired and the evidence it stood on. | (3) cataloging code | Provenance annotation of inferred values happens where inference happens — in cataloging, not in the agent. |
| R-21 | IV §6 (S10R9) | Review dispositions become case law: a reviewed row carries a durable marker naming the ruling; marked rows leave the control counts so any future hit is a fresh signal; a genuinely new class escalates to a human instead of being decided. | (3) cataloging code | Review-decision persistence semantics; production review flow (DocumentReviewService) is the natural home. |
| R-22 | IV §4 (S10R9) | Payment-control-sheet values are ground truth against inference only — never hard truth in themselves; they outrank internal inference but not a bank movement or the counterparty's own statement. | (5) prototype-only | Payment/receivable control-file and matching-tolerance mechanics; out of extraction scope. |
| R-23 | IV §2 exception (S10R9) | A counterparty's own account statement outranks any internal reconstruction of the same fact, whatever tier the reconstruction claims. | (5) prototype-only | Bank-reconciliation evidence ranking; out of extraction scope. |
| R-24 | SKILL.md §18 "Evidence and Logic Control" session rule (S10R9) | When an instruction or document contradicts recorded facts, produce an evidence-cited report before applying anything — never apply silently, never refuse silently. | (6) already covered | For the extraction boundary this is 2.3 rule 13 (compare, warn, never repair) and the QR-conflict rule (never override silently, emit conflict warning, reduce confidence); the operator-side behavior belongs to the human/orquestrador loop, not this profile. |

### E. Classification and cataloging

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-25 | IC §2 (S10R9) | A classifier consults its sources in a stated, evidence-ranked order and stops at the first match; the resolution order is part of the rule, not an implementation detail; the fallback bucket is what is left when nothing resolves — never a positive identification. | (3) cataloging code | Entity/item resolution order over alias tables and learned identifiers (ENTALS-class data). |
| R-26 | IC §3 (S10R9) | A pattern-inferred classification may PROPOSE a master-data change; it may never write one — nothing reaches master data until a human decision is recorded; auto-created placeholder rows stay flagged until resolved. | (3) cataloging code | Sibyla's recent governed Entity-360 alias-write work (commit a6b70fc on main) already follows this propose-then-approve shape; verify parity in phase 2. |
| R-27 | IC §4 (S10R9) | A human classification is sticky: classification loops skip rows a human has decided; a classifier that "improves" a human answer is a bug. | (3) cataloging code | Master-data write-protection semantics. |
| R-28 | IC §5 (S10R9) | Inference decays into evidence: a resolved inference persists itself as an explicit reference row so the same input resolves by exact match next run — the system gets more certain over time instead of repeating a guess. | (3) cataloging code | Reference-data growth mechanics. |
| R-29 | IC §6 (S10R9) | Fix a misclassification at the record that owns the value, never at a derived/display table; verify the fix on the rendered output, because every denormalized copy needs its own resync. | (3) cataloging code | Master-data ownership discipline. |
| R-30 | IC §7 (S10R9) | One resolution helper per lookup kind; entity-to-item matching is a direct code lookup, never fuzzy legal-name matching — a similarity score once manufactured confident false positives from shared generic words; any fuzzy proposal is hand-checked against the entity master. | (3) cataloging code | Resolution-engine design constraint. |
| R-31 | Document Entry Line Classification Policy correction C-17 (S10R7) | Line-classification precedence is four tiers — company override, entity override, entity-item mapping, item default — the two override tiers are seeded-once governed overlay data; creating one is a governed master-data update, never an inline shortcut to make one document classify. | (3) cataloging code | ENTITM/ITMCLS territory. |
| R-32 | lessons-learned "a classification rule is a contract with wording" (S10R7) | Text-pattern flag rules go stale silently as upstream wording drifts; a detector must be asserted on the instances it actually produces, not on its catalogue row existing; when widening a pattern, make sure genuinely distinct content keeps its own signal instead of being absorbed. | (3) cataloging code | DOCEFL-class rule-catalog maintenance; applies to any future Sibyla warning/flag taxonomy code. |
| R-33 | SKILL.md §18 "Flag Relevancy" (roadmap 111, S10R9) | Every flag rule carries a governed relevancy: consultive (informational, ignorable by design) vs important — defined as: the document cannot be accepted as an invoice or bank statement, the entity is not identifiable, or the numbers do not match or cannot be read; a new rule must be classified at creation, never defaulted. | (3) cataloging code | Severity taxonomy over the flag catalog; maps loosely onto production's warning codes + review routing but is a worker/UI concern, not agent prompt discipline. |
| R-34 | SKILL.md §7 OFDGAP governance (roadmap 108, S10R8) | An expected-document-gap detector must be governed with decision memory: a gap someone reviewed and dismissed never returns; a gap whose document arrives auto-resolves; open gaps route to review with permanent identities. | (3) cataloging code | Depends on prior-document history per provider; out of agent scope by definition. |
| R-35 | SKILL.md §12 related-party rule (roadmap 110/C15, S10R8) | Related-party counterparties are a recorded master-data fact plus a classification, and any special treatment requires BOTH conditions — the entity flagged AND the specific movement classified as intercompany — never the entity alone, because dual-role counterparties exist. | (3) cataloging code | ENTMST field + ITMCLS class join; also encodes the dual-role caution for matching exclusions. |
| R-36 | SKILL.md §12 SNC mapping (S10R8, roadmap 95); `Specs/Change Log/_S10R8_entry_to_append.md` | Item-to-account mapping is inferred on a five-tier evidence cascade, strongest first (single-account matched posting → entity+item → entity+side → entity → item); a posting that splits across accounts is excluded from every entity-level tier; every written row records which tier produced it, and unevidenced rows are labelled as such rather than passed off as verified. | (3) cataloging code | SNCACC/ENTITM mapping mechanics; the provenance-label idea (record the evidence tier on every mapped row) is worth carrying into Sibyla's cataloging design. |
| R-37 | SKILL.md §12 (S10R8) | Account mappings live on the master tables and resolve onto documents through the item join at build time; documents never carry a denormalized account of their own. | (3) cataloging code | Master-data normalization decision. |

### F. Entity identity

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-38 | Entity Entry Flow Procedure §4 correction C-10 (S10R7); S11 Round 6 entry (395f433) | Fiscal-number normalization must carve out the approved synthetic-identifier format (which legitimately contains punctuation); the synthetic sequence is ONE global zero-padded counter, never per-country; the format detector accepts both legacy and current shapes, requires a country, and raises on an unknown one rather than guessing. | (3) cataloging code | Entity-master identifier issuance/validation; agent-side identifier transcription is already covered by 2.3 rule 3 (preserve as printed). |
| R-39 | Entity Entry Flow Procedure §4 addition (S10R7) | A fiscal number is not unique by itself: legitimately shared identifiers exist (one legal person trading under several names; branches sharing a registration), so any identifier-keyed lookup or dedup must expect multi-row keys with a secondary distinguishing field. | (3) cataloging code | Affects Sibyla entity resolution and the S15 party model; §Next's aggregated-invoice scenario partially exercises it. |
| R-40 | Entity Entry Flow Procedure §3 correction C-09 (S10R7) | Operational/derived per-entity fields (billing frequency, expected values, open balances) are engine-internal inputs, not entity master data — they must not be rendered or maintained as master data, but their internal existence is legitimate and load-bearing. | (3) cataloging code | Master-data vs derived-control-data boundary. |

### G. Archiving and storage (noted; largely out of scope)

| ID | Prototype source (introduced) | Rule (paraphrase) | Disposition | Reason / cross-check |
|---|---|---|---|---|
| R-41 | SKILL.md §16 (S10R7 gap G-10/conflict C-01; S10R9); Document Archiving Policy C-01; `_blockI_entry.md` | Never repoint a logical join key to fix a physical-file problem — fix the physical name; the originally-captured filename is written once and never rewritten; archive status needs a vocabulary distinguishing the several meanings of "no file"; environment guards must prevent an audit run in the wrong environment from rewriting real audit truth. | (5) prototype-only | Prototype workbook/folder/archive mechanics. Production already separates concerns: immutable original store keyed by content hash, metadata in PostgreSQL. The transferable ideas surface in R-04 (content binding) and R-03 (name is not identity), both already rowed. |
| R-42 | FDCP "Company assertion" absent-identity branch (S10R8) | A document legitimately printed with no buyer identity (simplified-invoice/final-consumer pattern) is an accepted, flagged capture outcome — not an error and not a mismatch. | (4) golden-set scenario | Extraction side already handled by 2.3 rule 9 (`ZZ`/`UNKNOWN`, never guess) and the QR final-consumer-sentinel rule; what is missing is regression coverage — no §Next scenario exercises an absent-buyer-identity document. Scenario G-d. |

## Summary counts

| Disposition | Count | Rows |
|---|---|---|
| (1) agent instruction | 2 | R-02, R-12 |
| (2) extraction contract / deterministic validator | 3 | R-04, R-07, R-17 |
| (3) cataloging or classification code | 26 | R-05, R-06, R-10, R-13–R-16, R-18, R-20, R-21, R-25–R-40 |
| (4) golden-set scenario | 1 | R-42 |
| (5) prototype-only / out of scope | 3 | R-22, R-23, R-41 (+ the catch-all list below) |
| (6) already covered — no change | 7 | R-01, R-03, R-08, R-09, R-11, R-19, R-24 |
| **Total rules** | **42** | |

## Golden-set scenario additions

Additions/refinements to `docs/golden-documents.md` §Next, appended there by this same merge
request (the §Next block added 2026-08-19 already covers the rest — nothing below duplicates it).
Scenario descriptions only; entries are pinned later by path + SHA-256 per the golden-documents
rules.

- **G-a — locale-formatted amounts** (from R-02): a document printing monetary values with spaces as thousands separators and/or comma decimals, which must be extracted as correct JSON numbers.
- **G-b — stated service period differing from issue month** (from R-12): an invoice printing a coverage/service/traffic period other than its issue month — ideally one advance-billing and one arrears variant — exercising `periodStart`/`periodEnd`.
- **G-c — consolidated multi-month invoice** (from R-12): one document explicitly naming several billed months.
- **G-d — absent buyer identity** (from R-42): a simplified-invoice/final-consumer document with no printed buyer identifier, which must extract with `ZZ`/`UNKNOWN` and proceed flagged, not fail.
- **G-e — credit note referencing its original** (refines §Next's credit-note scenario, from R-14): the visible reference to the reversed document must be extracted verbatim.
- **G-f — punctuated document number** (from R-04): a document whose printed number carries separators/spaces that must be preserved verbatim yet remain matchable to a normalized identifier under a digit-boundary rule.
- **G-g — cross-currency near-duplicate** (from R-07): two records of one document identity denominated in different currencies, which must not be reported as an amount conflict.
- **G-h — same-group different-company billed-to** (refines §Next's billed-to mismatch, from R-10 and the Stage 11 Round 1 entry): a document addressed to a sister/group company rather than a stranger — the subtler mismatch shape.
- **G-i — foreign identifier type** (from the Stage 11 Round 1 entry): a document printing a non-Portuguese, non-EU tax identifier type, exercising `identifierType` extraction without guessing.

## Recorded open questions (for phase 2, not decided here)

1. **Roles & Responsibilities policy scoping (correction C19).** The prototype ruled the "User and AI Roles and Responsibilities" draft is scoped to Sibyla (AI proposes, .NET executes) and will not govern the prototype. Should Sibyla now formally adopt it — and in particular its confidence/consistency/risk-threshold clause, which the prototype flagged as the ONLY link tying tolerance changes to a policy pre-flight? Without an equivalent, a tolerance change is the class of change most able to quietly widen autonomous action in production too.
2. **E&L threshold values (R-17).** The prototype's plausibility windows (days before/after, months of drift) were calibrated on the confidential corpus. Should Sibyla adopt the checks with its own thresholds as worker gates in a v3.2/next validator round, or keep them operator-side review heuristics?
3. **Prototype pin bump.** `hermes-documental-agent-instructions.md` (2.3) and other production docs reference the prototype at `9359c67` (2026-08-04). Should phase 2 bump the referenced pin to `395f433` when instruction changes from R-02/R-12 land, so instruction provenance and this matrix cite the same commit?
4. **Content-binding validator (R-04).** Agree to implement as a deterministic post-store check (stored fiscal document number must appear, digit-boundary-normalized, in the stored extraction text)? If yes: does it belong in DocumentValidationService gates or a separate audit job, given "no text layer" must be a third verdict, not a failure?
5. **Duplicate-conflict tier (R-05).** Production's original-hash uniqueness covers byte-identical resubmission. Should the same-identity-different-content CONFLICT tier (needs a human, never auto-resolved) be modeled in S2, or deferred with the §Next near-duplicate scenario as the placeholder?
6. **Instruction-language fit for R-12.** The stated-period reading guidance inevitably names Portuguese billing phrasings generically (as 2.3 rule 8 already does for collection notices). Confirm that citing generic phrasing patterns — with no corpus values — is acceptable in the instruction file.
7. **Where do (3)-disposition rules get tracked?** 26 rows land on cataloging/classification code that largely does not exist yet in Sibyla. Should phase 2 file them as V6/S-series backlog items individually, or adopt this matrix's IDs as the tracking register?

## Completeness check — every changed .md file accounted for

Re-ran `git diff 9359c67 395f433 --stat -- '*.md'` (62 files). Mapping:

**Rule-bearing, represented in the matrix:**
- `SKILL.md` + `Specs/Skill/SKILL.md` (byte-synced deploy copy): R-01, R-03, R-04, R-10, R-11, R-13, R-17, R-24, R-33–R-37, R-41 + disposition-5 items below.
- `Specs/Engagement Rules/Accounting Conformance Rule.md` (new): R-12–R-16.
- `Specs/Engagement Rules/Inferred Values Procedure.md` (new): R-18–R-23.
- `Specs/Engagement Rules/Inferred Classifications Procedure.md` (new): R-08, R-25–R-30.
- `Specs/Engagement Rules/Data Calculated Procedure.md` (new): mostly pipeline-engineering rules (one owner per field, determinism, idempotency, text-at-rest typing, resync per denormalized copy, derivation registration) — not document-reading rules; noted as (5)-adjacent engineering guidance already native to Sibyla's typed-contract/EF model; its evidence-tier content is R-18.
- `Specs/Engagement Rules/Financial Document Capture Policy.md`: R-05, R-08, R-09, R-10, R-42 (+ archiving-timing correction C-02 → (5), archive mechanics).
- `Specs/Engagement Rules/Document Entry Line Classification Policy.md`: R-31.
- `Specs/Engagement Rules/Entity Entry Flow Procedure.md`: R-38–R-40.
- `Specs/Engagement Rules/Document Archiving Policy.md`: R-41.
- `Specs/computed-fields.md`: AccountPeriod ownership pointer → R-12/R-13.
- `Specs/Lessons/lessons-learned.md`: R-02, R-04, R-07, R-32 (+ (5) ops lessons below).
- `Specs/Lessons/known-limitations.md`: context for R-03/R-32; validator-not-built correction → (5) below.
- `_to_delete/blockI_260808/_blockI_entry.md`: R-41 (evidence-over-inference recovery, join-key lesson).
- `_to_delete/blockJ_260808/_blockJ_entry.md`: R-06.
- `_to_delete/blockL_260808/_blockL_entry.md`: R-02, R-04 (reverse-direction audit).
- `_to_delete/blockE_260808/_blockE_entry.md`, `_blockF_entry.md`, `_blockG_entry.md`: block-work
  entry notes whose rule content reached the matrix through the files it landed in — blockE's
  recurring control-file import is in the SKILL.md not-rowed list below; blockF/G's substance is
  the four procedure files and the ACR (blockG is the ACR's origin note). No unique rules.
- `Specs/Change Log/_S10R8_entry_to_append.md`: R-36.
- `Specs/Change Log/_applied/_S11R1..R6R7`: R-38 (S11R6), G-h/G-i scenarios (S11R1); S11R2–R4 are code-issuance-ledger mechanics → (5); S11R7 is receivable-ageing/control-table feeding → (5).

**Disposition (5) / not rule-bearing (with reason):**
- `Specs/Engagement Rules/Bank Movement Reconciliation Procedure.md` (trim to a pointer, C-16): bank-reconciliation mechanics — excluded by task scope.
- SKILL.md sections not rowed: waiver lifecycle (RecheckDate governance), recurring control-file import procedure (roadmap 134), registry-scope boundary object (§5 addition), Consistency control 113, Issues-register six pipeline controls, ratio-must-name-its-population reporting rule, Roadmap/Process Control workbook mechanics, skill-package sync, `validate_registry.py`/`recalc.py` not-built/retired corrections, orphan generated-row closure — workbook/pipeline/programme governance, not document reading. (The R&R-policy scoping change is carried as open question 1.)
- lessons-learned ops entries: stale-mount/staging cache, package-member sourcing, sync-that-deletes — prototype tooling operations.
- `Backups/Control Log.md`, `Specs/Change Log/Invoice Registry Change Log*.md` (incl. the device-tagged and `_pre` copies), `Specs/Skill/Skill Review Log.md`, the `_pending_roadmap*_applied.md` notes, `_rescued_260805/*`, `Specs/Roadmap/Roadmap.md` + `Roadmap_Proposals.md`, `_to_delete/backup_sweep_260805_1333/Logs/*` renames: chronological logs, planning and housekeeping — no new reading rules beyond what the rowed files carry.
- `Inputs/Corrections/p1-0-corrections.md` + `p1-0-confirmations_260806.md`: the C-series decisions themselves — every reading-relevant one (C-03, C-07, C-08, C-09, C-10, C-12, C-15, C-17, C19) reached this matrix through the policy files it amended; the rest are Sibyla-schema decisions already integrated into GOTT.Sibyla via P1-0.
- `Editor/Data/_to_delete/_push_skill_tmp/*` (SKILL.md, lessons-learned.md, Skill Review Log.md), `Editor/Data/_to_delete/_ps3/*`, `_to_delete/blockE/F/G_*_stage/*`: staging duplicates of files already rowed (verified: block E/F/G stage dirs hold earlier SKILL/procedure snapshots superseded by the canonical copies).
- `_to_delete/s10r08_transfer_zips/_fresh_skill_260806.md`, `_fresh_ll_260806.md`: intermediate transfer snapshots, diffed and confirmed subsumed by final `SKILL.md`/`lessons-learned.md` (no unique rules).
- `Specs/Change Log/_S10R8_entry_to_append.md` rowed above; `_applied/_S11R2/R3/R4` are permanent-code-ledger mechanics — explicitly excluded as code-issuance ledgers.

No changed markdown file remains unaccounted for.