Semantic columns, not form widgets

Claim: meaning lives in a type catalog

Slots, not a blank page fixed the document model: category, template, item, field type. This essay names the hinge that makes cross-domain structure work: field meaning is global.

In NT² Vault, a field is not primarily a widget. It is a semantic column type—a stable identity in a registry. The UI may render that type as a secret input, a date picker, or a blob attachment slot. Those editors are implementation. The product contract is the type: what the value means, which capabilities it carries, and how it is addressed when the item leaves RAM as ciphertext.

The claim: semantic columns beat per-screen form widgets when one vault must serve credentials, banks, documents, IT assets, and more without inventing a parallel type universe for each vertical.

The constraint: widget keys do not travel

Early structured apps often model forms like this: placement key password, widget type secret, store { "password": "…" } in JSON. That works for one template. It fails when the product grows.

Keys become folklore. Is the account number accountNumber, account_no, or acct? Different templates invent different strings. Search projection, share masks, and migrations must special-case every synonym.

Widgets are not meaning. A text widget can be a bank name or a recovery hint. A secret widget can be a password or a TOTP seed. Cross-cutting features cannot ask “is this an expiry?” by looking at the widget kind.

Wire shape couples to UI accidents. If durable ciphertext embeds free-form string keys from the form author, renaming a label or splitting a screen becomes a storage migration. Portable backups and replica batches inherit the mess.

Extension becomes plugin theater. The tempting escape is “let users define field types” or “let packs ship JavaScript editors.” That path turns a local vault into an extension host with an unbounded trust and compatibility surface— the opposite of a small, auditable crypto and schema core.

NT² needed a registry where one FieldTypeId means one thing everywhere, and where new domains reuse or carefully extend that catalog instead of forking it.

The design: FieldTypeId, capabilities, stable indices

Semantic identity

Each field type has a stable identifier—the domain key you reason about in product language: password, username, expiry date, IBAN, document number, and so on. Templates do not invent private key strings for secrets; they place registry types into an ordered schema.

Authors pick semantics. They do not pick “I want a rounded text box.” The editor kind (secret, date, multiline, blob reference, …) is derived from the type definition so the UI stays consistent and the storage layer stays boring.

Capabilities, not category folklore

Type definitions carry capabilities—machine-readable flags and defaults that other subsystems read:

• whether a value may be projected into local search text;
• whether it should be masked until revealed;
• default share / present sensitivity;
• participation in recipes (for example, “this set of fields looks like a bank summary” or “this row has a password worth scanning”).

Those capabilities are why an expiry date on a passport document and an expiry date on a TLS certificate can share reminder behavior without each category hard-coding a private mini-framework.

Stable indices on the wire

In memory and in domain code, values are addressed by semantic id. When fields leave RAM as a sealed payload blob, they are addressed by stable numeric field indices from the registry manifest—not by scattering password-shaped string keys through ciphertext. The companion essay CBF is how structured fields leave RAM covers the container; the registry is why the blob stays evolvable.

flowchart LR
  Author[Template author] --> Place[Place FieldTypeId]
  Place --> UI[Editor from type def]
  Place --> Caps[Capabilities]
  Place --> Wire[fieldIndex in payload blob]
  Caps --> Search[Local search projection]
  Caps --> Share[Share / present defaults]
  Caps --> Features[Health, expiry, …]

Packs merge into one catalog

Field definitions ship as data packs that merge into a single registry at runtime. Core types cover everyday secrets and notes. Domain packs add financial, IT, medical, and other vocabularies without requiring each pack to redefine “password” or “date.” Category templates then compose those types into schemas—the next essay in this series.

Customization tiers without new types

The product still needs flexibility. The registry model allows template-level and sparse per-item extras built from existing types. What it does not allow is end users minting novel field types with novel wire indices from the settings UI. Structure scales by composition and curated catalog growth—not by turning every vault into a type compiler.

The trade-off: curated meaning over infinite DIY types

A closed semantic catalog feels stricter than “add any field.” That is intentional.

New domains still ship. They ship as packs that reuse types where possible and add carefully versioned types when the catalog truly lacks a concept. That is slower than a freeform key—and vastly cheaper than maintaining five synonyms for “account number” across search, share, and backup.

What we refuse

We refuse user-defined field types as a product escape hatch. Custom templates may arrange existing types; they must not become a side-channel type system that bypasses the registry.

We refuse executable pack JavaScript as the way to grow fields. Domain and community packs should stay data plus declarative rules. A vault that evaluates untrusted editor code to understand a date field has left the structured-asset plot.

We refuse widget kind as the source of truth. Editors render types; types do not collapse into editors.

We refuse free-form secret keys inside durable ciphertext. Stringly-typed payloads are how blank pages return after encryption.

From widgets to columns

If you have ever migrated a form and discovered three names for the same secret, you already know why semantic columns matter. NT² makes that lesson a registry rule: meaning is centralized; screens are projections.

Continue with Compose domains from one type system— how field packs and category packs turn one catalog into many verticals. For the sealed blob those columns become, read CBF is how structured fields leave RAM.

Try the structured vault at NT² Vault, or read more at nt2.me.