Four surfaces, one field set

Claim: one resolved field set, four jobs

Searchable metadata, sealed field values drew the storage boundary. This essay closes the first arc of the structured document model series: how the product uses fields after they exist.

The claim: edit, view, present, and features share one active field set. There is not a form schema, a share schema, and an expiry schema that happen to look similar. There is one resolved set of semantic fields for the row—template placements plus any per-item extras—and four surfaces that project it.

That sounds like UX polish. It is a security boundary. Parallel models drift. When they drift, selective disclosure becomes aspirational copy, and “show the officer one number” quietly becomes “export the whole note.”

The constraint: parallel models leak

Product teams often split concerns early:

• the edit form’s field list;
• the detail page’s display layout;
• the share dialog’s checklist;
• the reminder job’s hard-coded category columns.

Each list starts equal. Then someone adds a field to edit and forgets present. Someone adds a presentable field that edit never validated. Someone gates expiry on category === "document" while a certificate template uses the same semantic date under another slug.

Drift creates over-disclosure. Share defaults copied from a stale list expose more than the current item holds—or the opposite: hide the one field the recipient needs and train users to send screenshots again.

Drift creates dead features. Reminders that only understand one category miss every pack that reused the expiry type correctly.

Drift creates two sources of truth. Encryption and CBF seal whatever the save path encoded. If present reads a different map, you are no longer reasoning about the sealed item; you are reasoning about a UI shadow.

The constraint: surfaces may differ in chrome and policy; they must not differ in which semantic fields exist on the row.

The design: resolve once, project four ways

Active field set

For an item, the vault resolves:

1. the category template’s ordered placements;
2. sparse per-item extras from the registry;
3. each placement’s type definition (capabilities, editors, defaults).

That bundle is the active field set—the same idea Compose domains from one type system used for feature gating.

Four surfaces

flowchart TB
  Active[Active field set]
  Active --> Edit[Edit]
  Active --> View[View chrome]
  Active --> Present[Present / share]
  Active --> Feat[Features]

Edit binds editors from type definitions. A password is masked. A date uses a date control. A document photo uses a blob-shaped field, not a loose file with no semantic home.

View applies display profiles and bindings—how the item should look when you are reading, not editing. Chrome can emphasize issuer and expiry without redefining what those fields are.

Present / share applies stricter policy on top of the same set. Placement and type defaults mark what is hard-blocked, what is optional to include, and what safe presentation may show without handing over a permanent copy of everything. The share secret is not the master password—see Share passphrase is not master password— and the present surface is not “attach the whole ciphertext and hope.”

Features subscribe to capabilities and recipes on the set. Expiry pipelines fire when expiry semantics are present. Password health scans password semantics wherever they appear. List preview picks a non-secret hint field by priority. None of that requires a second schema document.

Policy is a lens, not a fork

Present may show fewer fields than edit. View may hide unlock-only secrets until revealed. Features may ignore empty values. Those are lenses over one set. When a new field is added to the template, all four surfaces learn it from the same resolution path—subject to each surface’s policy—rather than from four pull requests that might disagree.

The trade-off: narrower present, broader reuse

One field set makes “show less” the default engineering path for presentation: you subtract from the resolved set; you do not maintain a gift-basket of everything the form once had. It also makes features appear in unexpected but correct places—an API service template with a password field gets password habits without pretending to be a classic credential category.

The cost is discipline. New UI cannot invent a shadow field that never enters the active set. New packs must place real registry types if they want reminders and share masks to work.

What we refuse

We refuse a second data model for presentation. Present reads the item’s fields under policy; it does not keep a parallel “share payload” schema that can diverge.

We refuse dumping the full item as the default share. Selective disclosure exists so “see this field” does not mean “keep every secret on the row.”

We refuse feature logic that only knows three legacy slugs. If the semantic field is on the row, the feature should be able to see it—packs included.

We refuse teaching users that screenshots are the real present mode. When surfaces share one set, product flows can stay narrower than a camera roll.

Close the loop

This series argued a single spine:

1. Slots, not a blank page — document model
2. Semantic columns, not form widgets — registry
3. Compose domains from one type system — packs
4. Searchable metadata, sealed field values — storage boundary
5. Four surfaces, one field set — product projections

Together they are why NT² can span domains without a blank canvas and without a server that understands your fields. Structure is not decoration on ciphertext. It is the type system that makes local-first assets usable—and disclosure finite.

For identity and share boundaries beside this model, read Selective SSI — not a DID wallet. For the ciphertext shape behind every surface, read CBF is how structured fields leave RAM.

Try NT² Vault or explore nt2.me.