Field register method: building a register that tracks every passport field by type

A field register is a working document that lists every field a passport record must contain, organised by field type, with an owner, a source, an access tier and a status for each field. The register is not the passport. It is the tool that allows an operator to build, check and maintain a passport without re-reading Annex XIII from the beginning on every occasion. A register that is built once and never updated becomes a source of error, because fields change with model revisions, delegated acts and status events.

A register that is updated with each change becomes the memory of the record system. The method below is written for a single model, and the same method scales to a model family by adding a model column.

What field types does a register use?

Field types separate fields by what kind of entry they are. Identity fields identify the manufacturer, the model and the unit. Value fields state a measured or declared value with a unit and conditions. Evidence fields point to a document, a test or a verification. History fields record dated events for the unit. Summary fields restate a value at a stated depth for a stated tier. The type decides the checks that apply. An identity field is checked for match across marking, record and declaration. A value field is checked for unit, scope, method and date. An evidence field is checked for retrievability and match. A history field is checked for date order and completeness. A register that lists fields without types invites the same check to be applied to every field, which is how value fields are checked without conditions and history fields are checked without dates.

How is a register row built?

Each row contains the field name as in Annex XIII, the point number, the field type, the access tier, the owner, the source document or system, the status, and the date of the last check. The owner is a role, not a named individual, such as product data owner, test owner or supply chain owner. The source is a specific document or system, identified by title and version or by system name and record reference. The status uses a closed set: present, partly present, missing, not applicable, not yet due. A free text status field invites vague entries such as in progress, which cannot be checked. The date of the last check allows a reader to tell whether a present status reflects a recent check or a check made before a model revision. The register should also carry a notes column for scope, method or timing qualifications that do not fit in the status.

What does a register excerpt look like?

How is the register maintained over time?

The register is maintained through version events. A model revision creates a new register version, with changed fields marked and dated. A delegated act that sets a new method creates a register update for the affected fields, with the timing note changed from expected to fixed where the act position settles. A status event for a unit does not change the model register, but it creates a unit register entry or a unit history update, depending on the system design. A correction creates a register entry that records the prior status, the correction and the date, rather than overwriting the row. Maintenance is assigned to the product data owner role, with input from test, supply chain, conformity and service owners. A register without an assigned maintainer drifts, and a drifting register is worse than no register, because it presents old checks as current.

How does the register support a record check?

A record check starts from the register, not from the display. The checker works through the register rows in point order, opens the record field for each row, and records the outcome against the row. The checker does not work from the display alone, because the display may omit restricted fields, may show a summary instead of detail, and may hide version history. The register therefore functions as a checklist with memory: it shows what was checked, when, by which role, and with what result. A checker who finds a field present in the display but absent from the register should update the register before concluding, because the register is the record of the check. A checker who finds a field in the register but absent from the display should record a gap, not assume a tier effect without checking the tier.

What limits apply to a register?

A register tracks fields and evidence. It does not prove that the evidence is correct, that a test was performed properly, or that a battery is compliant. Those conclusions require inspection of the evidence itself. A register also does not replace the passport. A complete register with an incomplete passport is a well documented failure, not a success. The register earns its keep by making incompleteness visible early, while there is still time to obtain the missing evidence. This guide gives general educational information only and does not give legal advice for a particular record system or operator.