# Data access request and semantics record

Access to a field does not establish that its meaning is understood. This document has two parts. The access request gives a data or control owner a concrete proposal to assess, instead of a broad request for "banking data". The semantics record keeps the meaning of each field with the solution, so that tests cover the meanings that affect the decision and a change in a source system triggers a review.

Source: article two, "Establish data access and data meaning together".

## Who fills this in, and what it decides

The FDE lead writes the access request after discovery is authorised; the data or control owner assesses each row and records the decision. The FDE lead starts the semantics record and hands it to the service owner at transfer; the owner named in each row is the person who resolves that field's meaning. Part one feeds the access decision and, where access is restricted, the design decision under "Restriction as design input". Part two feeds the evaluation and the reassessment triggered when a source or method changes.

Roles named in this document:

- Data and control owner: decides whether each field may be used, by which identity, and under which conditions.
- FDE lead: specifies what the solution needs and records the alternatives when access is restricted.
- Method owner: owns the meaning of the fields that carry the business judgement. In the specimen, the valuation owner.
- Business workflow owner: owns the meaning of the fields that describe the process itself.
- Service owner: maintains the semantics record after transfer.

## Part one: access request

- Workflow:
- Approved purpose, in one sentence:
- Processing environment:
- Requesting identity model: service account / requesting user's identity / mixed
- Retention:
- Requested by:
- Assessed by (data or control owner):

Column definitions. Identity that may retrieve it: the account or user under whose permissions retrieval runs. Fields, not tables: the specific fields the solution needs; a table request is refused as too broad. Authority for this field: the owner who decides whether it may be used. Decision: the owner's answer, with conditions noted in the row.

| Information required | System that holds it | Identity that may retrieve it | Fields, not tables | Retention | Authority for this field | Decision |
| --- | --- | --- | --- | --- | --- | --- |
| Target identifiers (specimen) | Deal system | Analyst identity | Legal entity id, ticker, sector | Engagement, then the owner's standard period | Deal team | granted / restricted / refused |
| Public filings (specimen) | Filings service | Service account | Document, period, filing date | Standard | Public | granted / restricted / refused |
| Deal-room documents (specimen) | Deal workspace | Analyst identity, selected files only | Named document set | Engagement only | Data and control owner | granted / restricted / refused |
| Prior screening outcomes (specimen) | Screening log | Analyst identity | Outcome, date, decided by | Standard | Banking workflow owner | granted / restricted / refused |
| | | | | | | granted / restricted / refused |
| | | | | | | granted / restricted / refused |

The specimen rows are hypothetical.

## Restriction as design input

Less access can reduce exposure. It does not automatically establish that the processing is allowed. When the owner grants less than requested, the FDE lead records the alternative design and the gap it creates, and the data or control owner reassesses the alternative against the actual use. The engagement brief's supported cases may need to narrow as a result.

| Requested | Granted | Alternative design | Gap it creates in the result | Reassessed by, and on |
| --- | --- | --- | --- | --- |
| Every document in the deal workspace (specimen) | Selected filings only | Narrow document set under the analyst's identity | Early diligence material absent from the brief | |
| | | | | |

## Part two: semantics record

One row per field that affects the decision. Maintained with the solution, and reviewed when the source system or the method changes. The specimen rows are hypothetical; the manufacturing row appears because certificate coverage exposes a different constraint, entity matching across subsidiaries, that the screening rows do not.

Column definitions. Authoritative source: the system whose value is used when sources disagree. Effective date rule: which date decides that a value is current. Known gaps: cases the source does not cover or covers inconsistently. Unresolved interpretation: a question the owner has not yet answered; the solution must expose it rather than guess. Test that covers it: the evaluation case that fails if this meaning is wrong. Owner: the person who resolves the meaning.

| Field | Authoritative source | Meaning | Effective date rule | Transformation applied | Known gaps | Unresolved interpretation | Test that covers it | Owner |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Enterprise value (specimen) | Market data service, not the research database | Market capitalisation plus net debt at the period end | Period end of the latest reported quarter | Currency converted at period-end rate | Research database stores an analyst-adjusted figure under the same name | Which figure the valuation owner wants in the comparison | Comparison test with both sources present | Valuation owner |
| Prior screening outcome (specimen) | Screening log | Could be a senior judgement, a temporary exception, or a value copied from another system | Date of the decision | None | Provenance not recorded before this year | Whether an outcome older than one year is admissible | Case with each provenance | Banking workflow owner |
| Certificate coverage (manufacturing specimen) | Certificate document | Issuing entity, issue date, expiry date, status | Expiry date | None | Subsidiary names differ from the legal entity register | Whether a parent certificate covers a subsidiary | Case per subsidiary pattern | Procurement |
| | | | | | | | | |
| | | | | | | | | |

## Change triggers

A change in a source system or a method can make a correct interpretation wrong. Record who is told, what they review, and which evaluation cases rerun before the solution continues to operate on the changed meaning. The service owner maintains this table after transfer.

| Event | Who is told | What is reviewed | Evaluation cases rerun | Decided by |
| --- | --- | --- | --- | --- |
| The method changes (in the specimen, the valuation method) | | Semantics rows owned by the method owner | | |
| A source system adds or renames a field | | Rows with that source | | |
| A new case type enters the population | | Supported cases in the brief | | |
| | | | | |

- Record maintained by, from transfer: