ADR-037: Per-Field Ownership Tables for Multi-Tenant Edit Surfaces; Backend Service Enforcement, BFF Reflection

The owning backend is defined as the service that owns the live data of a multi-tenant edit surface (e.g. craig-cases for case-detail fields) and already boots a zen-engine AuthzEngine. That service is where per-field ownership is enforced: it loads the ownership map, resolves each field to an effective permission, hosts the propose-approve queue, and emits the field-level audit. Pinning enforcement to the live-data owner is load-bearing for the §6 single-transaction guarantee (the queue and the live rows must share a database). craig-web stays a pure HTTP client: it asks the owning backend "what may this worker do with each field of this surface?" and renders the answer (§7). No database, message broker, or authz stack enters the BFF — its ADR-004 defining property is preserved.

Which backend owns the CWCA surface specifically — the existing craig-cases versus a NEW services/craig-cwca-provider — is a Plan Y authoring decision governed by an explicit rubric (see Open questions). A split to a new service is only valid when that service also owns the edited live rows; if the fields stay case-owned, the queue stays in craig-cases (§6). This ADR fixes only that enforcement lives with the live-data owner, wherever Plan Y pins it.

Field ownership has two separable axes, and conflating them into one artifact is the mistake to avoid:

The owning backend reads a field’s owner from the loaded ownership table and feeds it as a field_owner attribute through the already-present ResourceRef::attrs free-form map (the zen context already serializes attrs into resource.attrs via build_check_input, so a JDM rule reads resource.attrs.field_owner with no new plumbing on the input side). The output side is new: today AuthzEngine::check is strictly boolean (its parse_check_output reads only allow + reason), so per-field resolution is NOT an overload of check. Plan Y adds a new field-permission evaluation entry on craig-authz — a sibling to check and auto_scope_list — that evaluates the SAME {jurisdiction}-authz-<resource> ruleset (which gains owner-aware rows and a new permission output token) through a new output parser, returning a typed FieldPermission (§3). This reuses the ruleset + the ADR-024 cache + RMQ-invalidation infrastructure WITHOUT forking the {jurisdiction}-authz-<resource> naming into a -fieldauth- family or duplicating the per-resource coverage gate; the existing boolean check / parse_check_output are untouched. This honors the umbrella’s field_ownership.<surface>.<field> framing — that map IS the loaded table, consulted to produce the field_owner attribute the predicate reads.

CRAIG’s Action enum (Read / List / Create / Update / Delete / Approve) is a fleet-wide coupling: every value is serialized into every zen context and matched by every {jurisdiction}-authz-<resource> ruleset, and adding a variant is a boot-coverage obligation across the authz rulesets of both georgia/ and texas/. Field-level "propose" applies to a handful of shared fields on one surface; it must NOT pay that cost.

Instead, the §2 field-permission evaluation returns an effective permission read / write / propose / none — a typed FieldPermission, the role ListScope plays as the typed result of auto_scope_list. The owning backend’s surface handler runs the record-level check under the existing Action::Update, then resolves each touched field via the §2 path: write → direct write + audit; propose → an entry in the propose-approve queue (§6), never a live write; read / none → the field mutation is rejected. The owner’s accept of a proposed edit reuses the existing Action::Approve variant (documented for custom approve / promote handlers) — a fit needing no new verb. "Propose" is thus a per-field permission value the handler routes on, not a new record-level verb the policy engine arbitrates; the coarse Action enum and the boolean check are unchanged.

Per ADR-032 §4 + A11, the BundleContribution aggregate grows one additive field — field_ownership: FieldOwnershipContribution. Per A11’s requirement that the anchoring ADR document the field’s shape choice + cite ADR-038 §3: the contribution is pre-materialized (a value, not a boot-time factory — no per-state operator resource is needed at construction, ADR-038 §3). It carries a pre-materialized DECLARATION (which field-bearing surfaces the bundle provides + each surface’s field roster), NOT the owner classifications. The per-jurisdiction owner MAP is runtime-loaded by the owning backend from rulesets/<jurisdiction>/cwca_ownership.toml. This mirrors ADR-035 §8 exactly (the compositions field is a pre-materialized surface declaration; the jurisdiction baseline data is runtime-loaded from rulesets/, never bundle-embedded) and refines A11’s "static ownership mappings" wording, which read as bundle-embedded owner data: ADR-032 Amendment A13 records this refinement (the A12 precedent). The contribution is self-contained primitive data (&'static str field/surface names), so non-owning consumers of craig-state-bundle (the BFF, craig-exchange, craig-reporting) inherit no enforcement dependency, exactly as the compositions / theme / terminology fields do. A bundle with no field-ownership surface sets field_ownership: FieldOwnershipContribution::default() (the cheap empty default ADR-032 §4 requires). The exact payload is a Plan Y detail; the invariant fixed here is: pre-materialized declaration in the bundle, owner map on disk, never bundle-embedded.

The owning backend validates the ownership map at boot, fail-fast: every field in the bundle’s surface declaration must have an owner classification in the loaded cwca_ownership.toml, and every TOML entry must name a declared field. This is the field-ownership analogue of the composition required-floor and the authz coverage gate — a boot tripwire, so a missing field-ownership entry surfaces at the boundary, not as a silent un-enforced field discovered by an end user editing data they should not. (The umbrella risk register makes this boot check a Plan Y requirement: every field on every multi-tenant edit surface MUST have a field_ownership entry.) It mirrors ADR-036 §8’s structural boot gate and ADR-034 §8’s missing-locale gate.

Contract 5’s mandate is audit on every read AND every write (including propose + approve). This ADR preserves it in full — both halves are owning-backend obligations Plan Y must implement, via the existing per-service audit pipeline, NOT a new BFF audit path:

The propose-approve queue is a per-surface table — pending_edits_<surface> — on the owning backend’s database (NOT a BFF table). A non-owner’s proposed edit inserts a pending row attributed to claims.acting_worker() (ADR-028); no live row is touched. The owning role accepts or rejects from a queue served by accept/reject endpoints on the same backend (the accept gated by Action::Approve, §3). Accept applies the proposed value to the live row AND stages the field-edit audit event in ONE transaction — the transactional-outbox pattern (ADR-022) — so the live write and its audit cannot diverge. Because the queue and the live rows share one database (§1, owning backend = live-data owner), accept is a single local transaction; a cross-service accept-write is disallowed (it would break this atomicity). craig-cases already emits a field-level change event of this shape (publish_case_updated, {field, old_value, new_value}); Plan Y extends it with role + jurisdiction + the proposing/deciding worker subs on whichever backend owns the surface — this ADR does not assume the shape exists fleet-wide.

The BFF renders a lock-icon per field by fetching the backend-resolved per-field permission map for the acting worker, over the existing ADR-028 on-behalf-of seam — the exact flip craig-web already performs to reach craig-composition (its client_credentials service token + an X-Craig-Actor JWT for the worker; the backend resolves the map keyed on claims.acting_worker(), so the icons reflect the WORKER, not the BFF service principal). The lock-icon is a pure reflection of the backend’s authority — the load-bearing half of Contract 5’s "the lock icon is a reflection of this table, not the source of truth," with only the enforcement home corrected from BFF to backend. The BFF never decides; a tampered client that ignores a lock still hits the backend’s per-field enforcement (§1-§3). The transport shape — a standalone GET /v1/field-ownership/{surface} probe versus ride-along annotations on the surface DTO — is a Plan Y API-ergonomics detail (Open questions).

This ADR supersedes two Contract 5 statements that conflict with the backend-enforcement decision, the way ADR-036 superseded Contract 4’s disk-path home:

PRESERVED unchanged: the three-way ownership taxonomy, per-role per-jurisdiction enforcement, "propose is a write-shaped action producing a queue entry," mandatory audit on every read AND every write with role + jurisdiction + field + before/after, and field_ownership: FieldOwnershipContribution as the BundleContribution extension point.