# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## AMETA — Turn unbounded document metadata into a queryable contract A fictional records portal stores every property in one JSON column. Queries disagree about missing values, and malformed records make ordinary filters fail. **Field:** Database engineering. **Suggested stack:** PostgreSQL, Prisma, TypeScript, JSON Schema. **Engineer value:** Practice relational/JSON boundaries, versioned validation and query semantics. **Company value:** Review a data model that stays inspectable while allowing controlled variation. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create synthetic document metadata with malformed and legacy versions. - Use migrations and a local query API. ### Define metadata meaning Choose stable columns and bounded flexible fields. #### AMETA-101 — Separate stable document identity fields from flexible attributes **Task · Medium priority · Foundational** noCV practice brief v5 · AMETA-101 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define metadata meaning. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · System design 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Document owner, creation time and type are buried beside optional tags in JSON, so every query reinvents their shape. 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 - 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. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-102 — Define versioned metadata schemas with explicit size and depth limits **Task · Medium priority · Intermediate** noCV practice brief v5 · AMETA-102 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define metadata meaning. Depends on: AMETA-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · API design 30% · Security 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A client submits deeply nested metadata that the API accepts but later query code cannot handle. Acceptance criteria - Require an explicit supported metadata version. - Bound object depth, field count and serialized size. - Reject unknown protected fields and invalid field types. Implementation constraints - Use schema validation at the write boundary and safe error paths. Verification - Validate supported synthetic document metadata. - Exceed depth and size limits and verify no row is stored. Deliverables - Metadata schemas and bound checks Rollout and recovery: Deploy validation for new writes; quarantine incompatible legacy records. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-103 — Choose distinct semantics for absent, null and empty metadata values **Task · Medium priority · Foundational** noCV practice brief v5 · AMETA-103 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define metadata meaning. Depends on: AMETA-101, AMETA-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · API design 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A filter for documents without a retention tag returns different results depending on whether the field is absent, null or an empty string. Acceptance criteria - Define the three states for each supported filter. - Reject empty strings where they lack business meaning. - Publish a truth table consumed by query tests. Implementation constraints - Avoid blanket coercion of all empty-like values. Verification - Query one fixture for each declared state. - Send an unsupported empty value and verify validation behavior matches the table. Deliverables - Metadata null-semantics contract Rollout and recovery: Review the truth table with API consumers; retain old filter names until compatibility is documented. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Validate and migrate records Bridge legacy data while protecting writes. #### AMETA-104 — Extract stable document fields through an additive migration **Task · Medium priority · Advanced** noCV practice brief v5 · AMETA-104 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-101, AMETA-102, AMETA-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · Backend 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The model needs relational owner and created-at columns while old records and clients still use JSON. Acceptance criteria - Add nullable relational fields and required target constraints. - Keep original metadata available during migration. - Reject contradictory dual representations on new writes. Implementation constraints - Use a migration file and explicit data conversion rules. Verification - Insert a consistent bridge record. - Provide different owner identities in columns and JSON and reject the write. Deliverables - Schema expansion and bridge validation Rollout and recovery: Deploy additive schema before readers; rollback bridge code while retaining untouched metadata. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-105 — Backfill document timestamps without guessing missing offsets **Task · Medium priority · Advanced** noCV practice brief v5 · AMETA-105 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Data engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Legacy created-at values mix UTC strings with offset-free dates; blindly casting them uses the database session timezone. Acceptance criteria - Convert only timestamps with an unambiguous documented interpretation. - Quarantine missing-offset and malformed values. - Use resumable batches with counts by conversion outcome. Implementation constraints - Preserve original metadata for later review. Verification - Backfill valid offset-bearing values under two session timezones with identical UTC results. - Process ambiguous dates and retain null target fields plus explicit errors. Deliverables - Timestamp backfill and timezone regression Rollout and recovery: Dry-run first; pause on unexpected conversion categories and keep the checkpoint. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-106 — Keep document metadata updates under optimistic revision control **Bug · Medium priority · Intermediate** noCV practice brief v5 · AMETA-106 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-102, AMETA-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Backend 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Two editors update different metadata fields through whole-object replacement and silently overwrite each other's changes. Acceptance criteria - Require expected document revision on metadata mutation. - Validate the complete resulting versioned object. - Return a conflict without discarding either editor's input. Implementation constraints - Use explicit patch semantics; do not merge unknown nested arrays heuristically. Verification - Apply a patch at the current revision. - Race two patches and verify the stale one cannot overwrite the first. Deliverables - Revision-guarded metadata update Rollout and recovery: Canary patches on synthetic documents; restore read-only editing if conflict handling is incomplete. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-107 — Build parameterized metadata filters with an allowlisted operator set **Task · High priority · Expert** noCV practice brief v5 · AMETA-107 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate and migrate records. Depends on: AMETA-102, AMETA-103, AMETA-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A query endpoint interpolates client-provided JSON paths and operators into SQL. Acceptance criteria - Allow only documented fields and operators. - Bind user values as parameters and tenant scope as a required predicate. - Reject unsupported path syntax before query execution. Implementation constraints - Do not expose arbitrary SQL or JSON-path execution to clients. Verification - Filter known numeric and enum metadata under tenant scope. - Submit malicious path/operator text and verify no query execution or cross-tenant results. Deliverables - Safe filter compiler and injection regressions Rollout and recovery: Enable only reviewed filter combinations; disable newly added operators independently if checks fail. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Make filters trustworthy Verify query semantics and release the model. #### AMETA-108 — Verify metadata filter results against a simple reference evaluator **Chore · Medium priority · Advanced** noCV practice brief v5 · AMETA-108 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make filters trustworthy. Depends on: AMETA-103, AMETA-107. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Database engineering 50%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The database query for arrays and null values differs subtly from the API contract, making support reports inconsistent. Acceptance criteria - Author a bounded corpus covering all declared states. - Compare SQL result identities with a simple reference evaluator. - Report missing and extra identities separately. Implementation constraints - Use identical synthetic inputs and keep the reference implementation straightforward. Verification - Compare supported filters across the complete corpus. - Mutate one SQL null condition and verify the differential check finds the mismatch. Deliverables - Differential query harness Rollout and recovery: Require the harness for filter changes; keep the prior query compiler available for rollback. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-109 — Enforce required relational document fields after a clean backfill **Task · Medium priority · Advanced** noCV practice brief v5 · AMETA-109 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make filters trustworthy. Depends on: AMETA-104, AMETA-105, AMETA-108. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 100%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. New readers assume every document has a valid owner and UTC creation instant, but quarantined legacy rows still violate that assumption. Acceptance criteria - Check null, orphan and contradictory target fields before validation. - Keep quarantined records outside normal reader activation. - Add required constraints only after declared readiness passes. Implementation constraints - Do not fabricate missing timestamps to make constraints pass. Verification - Validate a fully resolved synthetic cohort. - Leave one ambiguous timestamp and verify readiness blocks activation. Deliverables - Readiness query and constraint migration Rollout and recovery: Activate resolved cohorts after verification; retain legacy quarantine and avoid destructive contraction. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### AMETA-110 — Rehearse metadata-schema rollback across old and new API consumers **Task · Medium priority · Expert** noCV practice brief v5 · AMETA-110 · Turn unbounded document metadata into a queryable contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make filters trustworthy. Depends on: AMETA-106, AMETA-108, AMETA-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · API design 20% · Platform engineering 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The team wants to remove legacy JSON fields immediately after switching reads, which could break old clients during a rollback. Acceptance criteria - Test old and new clients against the expanded schema. - Document the compatibility window and contraction prerequisites. - Keep versioned metadata and relational values coherent during rollback. Implementation constraints - Use synthetic records from every supported version. Verification - Switch readers and restore the prior compatible client with unchanged results. - Introduce an unsupported version and verify a clear failure rather than lossy conversion. Deliverables - Compatibility matrix and rollback drill Rollout and recovery: Retain bridge columns through the reviewed window; contract only after old writers are retired. Project prerequisites: Create synthetic document metadata with malformed and legacy versions. Use migrations and a local query API. Engineer value: Practice relational/JSON boundaries, versioned validation and query semantics. Company value: Review a data model that stays inspectable while allowing controlled variation. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.