Define versioned metadata schemas with explicit size and depth limits
A client submits deeply nested metadata that the API accepts but later query code cannot handle.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- JSON Schema · Resource limits
Estimated field mix
- Database engineering40%
- API design30%
- Security30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
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
Complete these dependencies, or supply their agreed outputs before taking this ticket.
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 to include
- 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.
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.