`objectstack validate` and `build` accept a dataset whose base object, `include` path and dimension/measure `field` paths all name nothing — the same walker already resolves date-macro tokens on the identical node

[os-warren]

Summary

An ADR-0021 dataset can name a base object that does not exist, join a
relationship that does not exist, and bind every dimension and measure to
fields that do not exist, and objectstack validate exits 0 with
✓ Validation passed. objectstack build also exits 0 and writes the dangling dataset
into dist/objectstack.json.

The sting is that the author-time rule pass already walks these exact nodes: a bad
date-macro token in a measure filter is caught, path-precise, on the same traversal.
So the machinery and the traversal are both present — only the reference resolution is
missing.

This is one level below #7529 (closed by #8902, which refuses a widget → dataset
binding that names nothing). This is the dataset → object/field binding underneath it.
A board can now be proven to point at a real dataset, and that dataset can still point at
nothing.

Measured

@objectstack/spec 17.2.0, @objectstack/cli 17.2.0, on objectstack-ai/duly
(3 datasets over duly_task). Each row is one mutation applied on its own, confirmed on
disk before running (old spelling absent, new spelling present), then reverted.

#	Mutation	pnpm validate
1	dimension field: 'period_key' → 'period_kee' (base field)	exit 0, passed
2	dimension field: 'duty.frequency' → 'duty.frequenci' (joined field)	exit 0, passed
3	measure field: 'last_update_at' → 'last_update_att'	exit 0, passed
4	measure filter key last_update_at → last_update_attt	exit 0, passed
5	include: ['duty'] → ['dutee'] (relationship does not exist)	exit 0, passed
6	object: 'duly_task' → 'duly_tsk' (base object does not exist)	exit 0, passed
7	duplicate measure name (schema superRefine)	exit 1 — caught
8	filter value '{7_days_ago}' → '{7_fortnights_ago}'	exit 1 — caught

Rows 7 and 8 are the control: datasets genuinely are in the validation path, so rows 1–6
are not "the file was never read".

Row 8's message shows the walker reaching all the way into a measure filter with an exact
path:

✗ Author-time rules failed (1 issue)
 • dataset "duly_stagnation": Filter value "{7_fortnights_ago}" is not a resolvable placeholder.
 It is sent to the data engine as a literal string, matches no record, and the surface renders empty.
 rule: filter-token-unknown at datasets[1].measures[1].filter.last_update_at.$lt

That message is the whole argument for this issue. filter-token-unknown already stands
at datasets[1].measures[1].filter.last_update_at.$lt and reasons about the value.
Nothing standing in that same position resolves the key — or the sibling
measures[].field, dimensions[].field, include[], or object.

Why this matters more for a dataset than for most metadata

filter-token-unknown's own wording states the failure mode it exists to prevent:
"sent to the data engine as a literal string, matches no record, and the surface renders
empty." A dangling field path produces the same outcome from the same node and is not
checked.

A dataset is the semantic layer: dashboards and reports bind its dimensions and measures
by name (ADR-0021), and the consumer end is now guarded (#8902). So the surviving failure
is the quiet one — every binding resolves, the board renders, and the charts are empty or
subtly wrong because the dataset underneath addresses columns that do not exist.

Row 6 is the one I would prioritise: a dataset over a non-existent base object is
unambiguously meaningless, has no forward-reference story worth preserving, and is the
cheapest possible check.

Precedent in the tree

The platform already resolves qualified field reads elsewhere and produces a good message.
From the same repo's flow-condition validation:

unknown field `needs_colection` on `duly_assignment` — did you mean `needs_collection`?

That is the message shape this wants. The resolver exists; it is not wired to dataset
field paths.

Related: #14089 (bare identifiers in flow conditions have no validation leg) is the same
family — a validator with a per-surface hole — though a different surface.

Suggested scope

1. Resolve Dataset.object against the object registry. (Cheapest, highest value.)
2. Resolve each include[] path hop-by-hop against the object graph, honouring the
   ADR-0071 3-hop limit that is already enforced structurally.
3. Resolve dimensions[].field and measures[].field — a base field, or a
   relationship[.relationship].field path whose relationship prefix must appear in
   include. That last clause is a second real check: a dot-path whose prefix was never
   declared in include is not joinable even if the field exists.
4. Resolve filter keys in Dataset.filter and measures[].filter, reusing the
   traversal filter-token-unknown already performs on the values.

Timing: validate/build at the latest, matching #8902's "refuse at publish at the
latest" posture for the layer above.

Reproduction

1. git clone objectstack-ai/duly, pnpm install.
2. In src/datasets/duty-health.dataset.ts, change object: 'duly_task' to
   object: 'duly_tsk'.
3. pnpm validate → ✓ Validation passed, exit 0.
4. pnpm build → exit 0; dist/objectstack.json contains the dataset with the dangling
   base object.

Filed from the duly dogfood application (objectstack-ai/duly#9).

[os-justin]

Triage → domain:devx · p2 · Bug. Part of a five-card author-time-validation family; see the shared-root note below.

Anchoring — measured, not inferred from the title. The card names filter-token-unknown as the traversal that already reaches the node. On origin/main (66ecc50a) that rule lives in packages/lint/src/validate-filter-tokens.ts, and the sibling resolution this card wants lives beside it in packages/lint/src/validate-widget-bindings.ts / reference-integrity-suite.ts. ⇒ the fix lands in packages/lint ⇒ domain:devx.

⚠️ Method note: my first query for these symbols returned zero across all five, and the zero was a broken pathspec, not a reading — caught only by re-running with packages/lint/src/lint-view-refs.ts (named by a sibling card) as a positive control. Recording it because a zero here would have mis-routed the whole family.

Type = Bug, not Feature. The mechanical boundary test asks whether the change widens the accept set: it narrows it. And ADR-0078 (no silently inert metadata) declares the invariant this surface fails to enforce ⇒ declared ≠ enforced ⇒ Bug. ⛔ Not a Feature despite reading like "add a new check".

Grade p2. Silent-empty render with all gates green, on the semantic layer that dashboards bind by name. ⛔ Not p1: authoring-time gap, no production outage, no security boundary. The consumer end above it is already guarded (#8902), which is precisely what makes the surviving hole the quiet one.

⭐ Shared root with #14148 and #14107 — one fix shape, not three

This card's suggested scope item 4 (resolve filter keys, reusing the traversal filter-token-unknown already performs on the values) is the same defect as #14148 §A, on a different node. Both cards independently observe: the walk already descends the filter tree and already knows the bound object; only the key resolution is absent.

And the resolution itself already exists a third place: dashboard-filter-field-unknown (packages/lint/src/validate-widget-bindings.ts, shipped #3382) resolves a dashboard-level filter's field against each widget's dataset base object, and prints the object's field list.

⇒ Filter field-key resolution is implemented in one of the three places it is needed. Whoever takes these should price them as one mechanism reused, ⛔ not three independent rules. Flagging for the lane's fold-or-serial call — this family shares hot files in packages/lint/src.

Priority within the card: the reporter's own ranking stands — row 6 (dataset over a non-existent base object) is the cheapest check with no forward-reference story worth preserving. ⛔ Do not let the harder include[] hop-walking (item 2) block shipping item 1.

Dedup: the card's own positioning is correct and I confirmed the relationship — #7529/#8902 guard widget → dataset; this is dataset → object/field underneath it. ⛔ No duplicate. Nearest live sibling is #14089 (bare identifiers in flow conditions), same class, different surface, already queued.

---

Generated by Claude Code