noCV
AMETA-101 · Define metadata meaning

Separate stable document identity fields from flexible attributes

Practice briefTaskFoundational

Document owner, creation time and type are buried beside optional tags in JSON, so every query reinvents their shape.

Focused work estimate
1h 30m + prerequisites
Priority in the scenario
Medium
Engineering practice
Data modeling · Schema boundaries

Estimated field mix

  • Database engineering70%
  • System design30%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional records portal stores every property in one JSON column. Queries disagree about missing values, and malformed records make ordinary filters fail.

Setup prerequisites

  • Create synthetic document metadata with malformed and legacy versions.
  • Use migrations and a local query API.

Preceding work

No earlier ticket is required. Complete the project setup above.

Acceptance criteria

  • List stable required columns and bounded flexible attributes.
  • Document ownership and nullability for each field.
  • Reject storing lifecycle authority in arbitrary metadata.

Implementation constraints

  • Use a small fictional record taxonomy.

Verification to include

  • Map two document types to the proposed model.
  • Classify an unknown authoritative status field as a schema decision rather than generic JSON.

Deliverables

  • Relational/JSON field map

Rollout and recovery

Review the field map before migrations; keep unresolved authority fields out of metadata writes.

Value of the work

For the engineer: Practice relational/JSON boundaries, versioned validation and query semantics.

For the team: Review a data model that stays inspectable while allowing controlled variation.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.