Meridian Field Services: instructional example, not project evidence
A closed set with anchored definitions (what qualifies is decided by content, not by vibes) and the handling matrix defined ONCE per level. Rows everywhere else cite a level and inherit its rules; per-row handling prose is the drift this matrix kills.
| Level | Anchor (what qualifies) | Example, this project |
|---|---|---|
| PUBLIC | Published service information | The customer-facing service catalog |
| INTERNAL | Operational data whose exposure inconveniences but does not harm | Reason-code meanings |
| CONFIDENTIAL | Business data whose exposure harms Meridian or a customer | Assignment history, job addresses |
| RESTRICTED | Personal data whose exposure harms a person | Technician location tracks |
| Level | Storage | Transit | Sharing | Display |
|---|---|---|---|---|
| PUBLIC | n/a | TLS | Open | n/a |
| INTERNAL | n/a | TLS | Staff | n/a |
| CONFIDENTIAL | Encrypted at rest | TLS | Role need | n/a |
| RESTRICTED | Encrypted at rest | TLS; never leaves the residency region (data flow & privacy[1]) | Named-role need only | Masked outside dispatch surfaces: positions render as bands, not coordinates, off the board |
Owner & change rule: N. Duval; additions or redefinitions by governance decision only; the set stays closed so every citation elsewhere stays resolvable. Contested classifications escalate to N. Duval.
Rows cite the data model's field ids; bare entity-and-field text is how registers rot. The data model's sensitivity-tag validator resolves against this register, both directions; a migration adding a personal field without a row here is a generation defect.
| Field (cites data model) | Type | Level | Special cat. | Purpose | Recipients |
|---|---|---|---|---|---|
| Position.lat, Position.lon[2] | Location data | RESTRICTED | no | Dispatch operations | Dispatch staff; no processors |
| Position.observed_at[2] | Movement pattern, when joined | RESTRICTED by association | no | Dispatch operations | Dispatch staff |
| Technician.name, Technician.hr_id[2] | Identity | CONFIDENTIAL | no | Dispatch operations | The board's read copy (system of record: HR[1]) |
| Job.address[2] | Customer site: a customer's location, distinct from technician location | CONFIDENTIAL | no | Dispatch operations | Dispatch + field staff |
| Assignment.reason_code, Assignment.note[2] | Worker-conduct records, when joined with identity | CONFIDENTIAL | no | Override telemetry: employment-notice discipline, §4 | Operations managers |
Special category: none in this project; the column says so explicitly, which is itself a claim. Records of processing: the purpose, category, recipient, and retention columns compile the processing record once; no second inventory.
"Keep for two years" is not executable without "from what, deleted how, unless what"; every row carries period, trigger, disposal, and the legal-hold override.
| Data class | Period | Trigger (runs from) | Disposal | Legal hold | Authority |
|---|---|---|---|---|---|
| Positions | 30 days | observed_at | Hard delete | Pauses deletion on N. Duval's written hold | Telemetry retention policy |
| Assignment history | 7 years | creation | Archive at 1 year; delete at 7 | Owner: N. Duval | Enterprise contract clause 14 (contract extracts[5]) |
| Jobs | Archived with their assignments | Archive-then-delete | Follows assignments | Operations policy | |
| Auth audit events | 2 years | event time | Hard delete | Owner: N. Duval | The audit-record rule the auth policy cites (audit events[3]) |
Reconciliation: matches the architecture's per-entity lifecycle rows exactly (data architecture[1]), checked, no divergence; a divergence is a defect, not a nuance. Rights versus holds: deletion requests yield to the contract-mandated assignment retention and to active holds; precedence stated, owner N. Duval.
The basis is chosen per processing purpose; consent is not a reflex. Capture and withdrawal mechanics exist only where consent IS the basis; the consent form scales with sensitivity in the governing regime.
| Processing purpose | Lawful basis (chosen) | Discipline it carries |
|---|---|---|
| Dispatch operations: jobs, assignments, positions | Contract performance + legitimate interest (field-service delivery) | Assessment attached for the location-tracking interest (legitimate-interest assessment[5]) |
| Override telemetry: reason codes, notes joined with identity | Legitimate interest under the collective agreement's monitoring clauses | Worker monitoring: the meaningful-notice obligation applies; the consent form scales with sensitivity in the governing regime (express versus implied); the dispatcher-facing notice is the open question the security requirements already track (§7), owner N. Duval |
| Marketing | No purpose exists (stated, so the absence is a decision) | |
Consent-based purposes: none, so no capture-and-withdrawal mechanics are owed; recorded. Were consent ever the basis, capture is granular per purpose and withdrawal is as easy as giving; a consent checkbox without a withdrawal path fails review.
Omission note: "cross_border_transfer omitted: processing is single-region; Restricted data never leaves the residency region by handling rule (§1), and no processor sits outside it; the model provider receives anonymized codes only, not personal data (SR-014[4]). Residency placement is the architecture's (data flow & privacy[1]). The trigger re-runs if a processor outside the region joins the integration register."
The trigger test always runs; only the assessment is conditional. Systematic monitoring of workers is the criterion that most often surprises delivery teams; it fires here.
Trigger test fires: systematic monitoring of workers (continuous location tracking of technicians during shifts). Other criteria: large-scale special-category processing, no; novel technology on personal data, no (the AI boundary receives anonymized codes only).
Assessment: attached (privacy impact assessment[5]), summarized here, analysis in the attachment:
| Question | Answer, citing its row |
|---|---|
| Necessity | Dispatch cannot assign on proximity without positions |
| Proportionality | 30-day purge (§3) · band-level display off the board (§1) · no off-shift tracking |
| Risks to subjects | Re-identification of movement patterns, mitigated by SR-033, SR-034[4] and the purge; the threat model carries the analysis row (TM-07[6]) |
| Residual risk | Signed by N. Duval, July 15, 2026 |
| Question | Owner | Answer by | Blocks |
|---|---|---|---|
| Does the dispatcher-facing monitoring notice require union co-signature before pilot start? Shared with the security requirements' question; tracked once, linked twice (open questions[4]) | N. Duval | Aug 8, 2026 | The override-telemetry purpose's notice text only |