What $ref'd component-schema drift looks like under a merge gate

Findings

3 breaking, 0 additive, 0 flagged as spec hygiene. Each finding cites the exact change-type, the surface affected, and the consumer impact. All three findings hit the same $ref'd component schema — the test case for the LED-1597 fix.

1. breakingfinding F1
   change type: field_removed (required field dropped)
   surface: #/components/schemas/Metadata.noticeAuthorLang

   The required string field noticeAuthorLang was removed from the Metadata schema. Metadata is $ref'd from NoticeSubmitRequest.metadata, which is the request body of /v3/notices/submit:POST — the endpoint eSenders call to publish a notice for OJS. noticeAuthorLang carries the EU official language (en, fr, de, etc.) the Contracting Authority wants Publications Office correspondence in. Code that constructs submit-request bodies against the prior shape and includes the field finds it silently ignored at the API surface; clients that omit it succeed where they previously failed schema validation. The change-type taxonomy fires field_removed at the schema path, not at the operation path, which is the test the LED-1597 fix added: a removal at #/components/schemas/<name>.<field> is surfaced as breaking even though the path-level operation declaration is byte-identical on both ends.

2. breakingfinding F2
   change type: required_field_added (new required field)
   surface: #/components/schemas/Metadata.noticeAuthorOrganization

   A new required string field noticeAuthorOrganization was added to Metadata. The shift in obligation is on the consumer: an eSender sending the prior, valid submit body — metadata: { noticeAuthorEmail, noticeAuthorLang } — now fails schema validation against the new spec because noticeAuthorOrganization is not present. New required fields are a strictly tighter contract on the client side and are classified breaking regardless of whether the server happens to default the value at runtime. The gate surfaces the requirement so the consumer can map it before publish, not after the first 400 in production.

3. breakingfinding F3
   change type: type_changed (string → integer)
   surface: #/components/schemas/Metadata.noticeAuthorEmail

   The noticeAuthorEmail property's type was changed from string to integer. The field name stayed the same. The required-set membership stayed the same. The path stayed the same. The only thing that moved is the wire type — and that is the failure mode this finding exists to catch. A consumer that hand-rolled the submit body around a string-typed email address now ships an integer-shaped value or fails schema validation. A consumer that ran openapi-generator against the old spec now has Java/Python/Go bindings with String/str/string typed fields that the new API rejects. The diff engine reports type_changed at the same component-schema path the prior two findings used, which is what makes the per-finding consumer-impact map readable: three breaks at one shared $ref site, three distinct change-type entries, one schema to re-pin.

What this report is not

Not a defect claim against the European Commission's TED v3 API. The drift in this report is a synthetic mutation we made to the live spec to demonstrate the engine. The real TED v3 spec at api.ted.europa.eu/api-v3.yaml is the baseline only.

The point of the report is the gap class, not the specific API. $ref'd component-schema field-level drift is a pattern that shows up everywhere OpenAPI 3.0 / 3.1 specs use $ref to share schemas across operations — which is most non-trivial specs. The TED v3 surface gives the demonstration a real-world shape, real procurement consequences, and a spec anyone can fetch and reproduce against.

The attestation artifact

A Delimit attestation is a bounded evidence record at a single spec pair. The same Delimit version run against the same two files produces the same bytes; that is the replayable property. The attestation does not opine on whether a change should have shipped, only on what shipped and how the change-type taxonomy classifies it.

For the precise list of checks, the explicit out-of-scope list, and the reproducibility guarantee, see the attestation methodology v1. This report is the OpenAPI-diff surface of the same primitive that powers the merge gate for AI-written code.

Reproduce this in your own repo

Anyone can re-run the analysis above and verify the same three findings come out. The full command sequence:

# Install the CLI
npm install -g delimit-cli

# Pull the live TED v3 spec as the baseline
curl -sL https://api.ted.europa.eu/api-v3.yaml \
  -o /tmp/ted_v3_baseline.yaml

# Make the drifted copy: edit #/components/schemas/Metadata
#   - remove noticeAuthorLang from properties + required
#   - change noticeAuthorEmail.type from string to integer
#   - add noticeAuthorOrganization (string), required
cp /tmp/ted_v3_baseline.yaml /tmp/ted_v3_drifted.yaml
# (apply the three mutations in your editor, or scripted)

# Run the merge gate
delimit lint /tmp/ted_v3_baseline.yaml /tmp/ted_v3_drifted.yaml

# Or the raw diff
delimit diff /tmp/ted_v3_baseline.yaml /tmp/ted_v3_drifted.yaml

If the output you get differs from the output in this report, that is itself a finding worth raising on the Delimit repo. The lint pass completes in well under one second on a standard laptop.