Field-Level Authority Matrix¶
Template — instantiates Bidirectional Consistency Mapping
States which side or decision rule governs each field and operation under defined conditions.
A Field-Level Authority Matrix is a fill-in table that answers, for every field in the paired scope, one question the sync can never leave implicit: when both sides can write, who governs this? Its defining idea is that authority is neither global nor symmetric — it is granted per field, per operation, and sometimes per lifecycle state — and that this grant must be declared as reviewable data rather than buried in connector code. Each row names a field; the columns state which side is authoritative, under what condition, what rule applies when both sides changed it, and whether the field is restricted. The matrix is a declaration of governance, not machinery: it does not move changes, hold conflicts, or run at runtime. It is the document a connector, a conflict queue, and an auditor all read to know the rules.
Example¶
A company syncs its HR information system (HRIS) with its payroll system. Both can edit an employee record, and a "last write wins" connector had been quietly letting payroll clerks overwrite job titles and HR overwrite pay rates. The team fills in an authority matrix. job_title → authoritative side HRIS, on conflict reject the payroll edit and notify. pay_rate → authoritative side payroll, always. preferred_name → either, compose (both may edit; most recent per person wins). home_address → HRIS, but marked sensitive: minimize so only the payroll-relevant postal region propagates, not the full street address. bank_account → payroll, sensitive: restricted, never propagated to HRIS at all.
The outcome is not a running system but a settled agreement. The next time payroll edits a job title, the connector — reading the matrix — rejects the write and surfaces it to the HR owner rather than silently clobbering the record, and the employee's bank account simply never leaves payroll. Arguments that used to happen after data corruption now happen once, on the template, before anything syncs.
How it works¶
- One row per field, columns for the whole governance question. Authoritative side, condition (e.g., "only while employment status = active"), conflict rule, and sensitivity class.
- Authority can be conditional. A field may be governed by HRIS during onboarding and by payroll after activation; the matrix records the lifecycle predicate, not just a static owner.
- Conflict rule per field, chosen from a fixed vocabulary. Reject-stale, authoritative-side-wins, compose, or escalate — declared here, executed elsewhere.
- Sensitivity is a first-class column. Fields are tagged restricted (never propagate) or minimize (propagate a reduced form), so the pair's data-exposure boundary lives in the same reviewable place as its authority.
Tuning parameters¶
- Granularity — whole-object, per-field, or per-field-per-operation authority. Finer granularity preserves legitimate local ownership but grows the matrix and its maintenance cost.
- Default stance — what an unlisted field inherits: no-propagation, symmetric, or a named side. A conservative default (no-propagation) fails safe.
- Conditionality depth — flat ownership versus lifecycle- or evidence-conditional ownership; conditions add fidelity but make the matrix harder to reason about.
- Change control — how tightly edits to the matrix itself are governed, and who may approve them; the matrix is a rights document, so its own authority matters.
When it helps, and when it misleads¶
Its strength is ending the false "single source of truth" claim. Most real pairs have distributed authority — one side owns some fields, the other owns others — and writing that down per field, including who may change the matrix, is what lets a team publish honestly which system of record governs what.[n1]
Its failure mode is drift between the document and the running connectors: an authority matrix that no code actually consults is decoration, and a stale matrix is worse than none because people trust it. The classic misuse is declaring global symmetry ("both systems own everything") because filling in the rows was hard — which reintroduces exactly the last-write-wins clobbering the matrix exists to prevent. The guarding discipline is to make the matrix the machine-readable source the connector reads, and to review it whenever a field or authority boundary moves.
How it implements the components¶
scoped_authority_and_propagation_policy— its core payload: the per-field, per-condition assignment of which side governs and may write.bidirectional_conflict_and_exception_policy— each row declares the resolution rule (reject-stale, authoritative-wins, compose, escalate) that applies when both sides changed the field.sensitive_field_minimization_boundary— the sensitivity column marks fields as restricted or minimized, keeping data-exposure limits alongside authority.
It does not implement human_adjudication_and_contestation_path — the matrix names which conflicts escalate, but the Synchronization Conflict Queue is where escalated cases are actually held, owned, and resolved. Nor does it implement the directional_transformation_pair; that belongs to the Forward/Reverse Field-Mapping Specification.
Related¶
- Instantiates: Bidirectional Consistency Mapping — the matrix externalizes the authority and conflict governance the pair runs on.
- Sibling mechanisms: Forward/Reverse Field-Mapping Specification · Synchronization Conflict Queue · Bidirectional Change-Data-Capture Adapter · Tombstone and Revocation Propagation
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Field-Level Authority Matrix operates as a non-executable information artifact that externalizes static or prospective structure because it states which side or decision rule governs each field and operation under defined conditions.
Independent corroboration: The frozen evidence defines Field-Level Authority Matrix as 'States which side or decision rule governs each field and operation under defined conditions', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Distributed-data and integration engineering is primary because per-field authority and conflict rules govern bidirectional synchronization. Organizational decision rights and audit controls materially shape ownership and sensitivity columns; the exact matrix is an encyclopedia synthesis specialized to governed data exchange.
Related originating lineages:
- Accounting & Auditing — Internal-control matrices materially shaped field ownership, segregation, and exception rules.
- Organizational & Management Science — Decision-rights matrices materially contribute the authority-allocation formulation.
Review resolution: Distributed-data and integration engineering is primary because per-field authority and conflict rules govern bidirectional synchronization. Organizational decision rights and audit controls materially shape ownership and sensitivity columns; the exact matrix is an encyclopedia synthesis specialized to governed data exchange.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- NARA: information-governance guidance
- NIST: systems security engineering and allocation of control responsibility
Notes¶
[n1] System of record — the designated authoritative source for a given piece of data. Bidirectional pairs rarely have one global system of record; authority is usually partitioned by field and operation, which is why publishing a per-field authority table (and controlling who may change it) is the honest form of the "single source of truth" claim. ↩