Build the solution · 1 / 5

Require the delivery identifier

Reject deliveries that cannot be tracked.

YOUR TASK

Make this happen

2 steps

Build the delivery JSON Schema with a required nonempty trackingId string and additionalProperties false.
Check the complete solution, then inspect any unmet requirements.

THE IDEA BEHIND IT

What this step adds

Build the delivery JSON Schema with a required nonempty trackingId string and additionalProperties false.

Files to work in

contract.json. Other files are the working baseline. New files include named resource skeletons and TODO guidance. Complete their fields and connect them using the objectives, schema completion and reference guide.

Start with the consumer

A delivery handler cannot correlate a message without its tracking identifier. Required controls presence; minLength controls empty text.

Schema versus payload

You are authoring the contract, not submitting a delivery. The external_schema resource stores a schema source. Processing and semantic indexing happen asynchronously on the platform.

Local IaC input checks and lesson contracts do not replace platform JSON Schema/OpenAPI processing. No external references, uploads or embeddings run here.

Files to change: contract.json

What you’re building: Define a reliable supplier delivery contract, then make its API discoverable.

Read the starter files

main.cococo

external_schema "supplier" {
  name = "Supplier delivery contract"
  format = "JSON_SCHEMA"
  sourceText = file("contract.json")
}

contract.json

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "Supplier delivery",
  "type": "object",
  "additionalProperties": false,
  "properties": {},
  "required": []
}

Reference: schemas · authoring schemas · external-schemas