docs: state a position on format assertion, and give the spec validation semantics

[fas89]

The conformance corpus surfaced this and recorded it as open: is format assertive in FLUID? The specification did not say, so the corpus took the weaker reading and put the assertive cases in optional/. Right call for a corpus — but it pushed the decision onto every implementer.

The position

format is an annotation, never an assertion. A validator MUST NOT reject a FLUID document solely because a string fails to match the format named for it; it MAY surface the mismatch as a warning.

Stated plainly rather than left to be discovered: a document that validates is not thereby guaranteed to carry a well-formed metadata.owner.email. Exactly three format keywords appear across all twelve published schemas — uri (54), email (17), date-time (10) — and all three are descriptive.

Why, beyond the 2020-12 default

Conformance must not depend on which validator you run. format vocabularies are optional in Draft 2020-12 and implementations differ in which formats they recognise and what they pull in to check them. Assertive format would make the same document conformant in one language and non-conformant in another — which defeats the purpose of publishing a corpus at all.

The choice is not symmetric. Declaring format assertive would invalidate documents that are valid today. That is a narrowing, which GOVERNANCE.md forbids between versions ("minor versions may add. They may not narrow") and scripts/check-compat.py enforces on every PR. Annotation-only is the only reading still available to a pre-1.0 spec that has already published twelve schema versions. A future version may add assertive checking behind a new opt-in keyword; it may not retroactively sharpen this one.

A gap this exposed

The spec had no validation-semantics section at all — it never said how a document is validated, which schema applies, or which draft governs keyword meaning. format merely happened to expose that. The new section covers all of it.

It also calls out a trap: FLUID has its own field named format — exposes[].binding.format (bigquery_table, snowflake_table, …) and the format keys in the acquisition blocks. Those are constrained by enum, and enum is assertive. The names collide and the annotation rule does not apply to them.

Worth recording: I initially believed bigquery_table was a non-standard format keyword in the schema and nearly shipped that as an argument. It is not — it appears only inside examples blocks, where it is FLUID's own field. A schema walker that does not know examples holds data misreads it. The claim was dropped and replaced with the two above, which are checkable.

Also corrected

The page claimed 0.7.4 was the latest published schema. It is 0.7.5.

tests/README.md

The question is kept, not deleted — marked answered and pointing at the spec. A question the corpus raised and the specification then settled is the outcome that section exists to produce; deleting the trail would hide that it was ever in doubt. The section is renamed from "Known ambiguities" to "Questions the corpus has surfaced", since one is now settled.

The second question — the reference implementation validating 2020-12 schemas with a Draft7Validator — stays open, and now has a heading of its own instead of being silently swallowed by the first.

Verification

No corpus data changed; the diff is two docs and one docstring.

Gate	Result
conformance/run.py	480/480, 0 failed, 0 unexpectedly passed
conformance/run.py --no-optional	478/478
tests/meta_test.py (as CI runs it)	19/19
check-compat.py pairwise 0.7.1→0.7.5	all 4 exit 0
specs/ regeneration drift	0 files (no schema/ change)

🤖 Generated with Claude Code