docs(obligations): OBL-004 — the graph-depth ceilings move here from UDLM

[croadfeldt]

Refs croadfeldt/udlm#487, croadfeldt/udlm#486.

UDLM capped three graphs — dependency depth at 10, relationship traversal at 15, composite nesting at 3, each with a per-profile table. All three are removed upstream.

That is a policy item, not a data model enforcement. The data models, the platform enforces.

Nothing structural makes depth 11 impossible — somebody picked 10.

What UDLM still guarantees

Only cycle detection, and the distinction is the point: a cycle is unorderable rather than merely deep — ordering derives from depends_on and a cycle has no first step. Structural impossibility, not a chosen threshold.

The model refuses what cannot be computed; policy decides what should not be permitted.

Four decisions, not one

"Pick a number" hides three others:

• Whether to cap at all. An estate may legitimately run uncapped on cycle detection plus operational review.
• Which depth. Dependency counts the provisioning chain; relationship counts traversal distance; nesting counts containment. A VM with 50 IP-address relationships has relationship depth 1, not 50 — a policy that doesn't say which it means will surprise somebody.
• When it's evaluated. Registration refuses a definition; request refuses an order. The second still admits a definition that can never be used.
• What a refusal says. UDLM's precedent throughout: name the chain and the depth reached, never "too deep".

The old numbers

Carried as a suggested starting point, explicitly not a requirement. Worth revisiting rather than inheriting — the composite row was a flat 3 with no profile variation, which is itself a signal it was never tuned against a real estate.

🤖 Generated with Claude Code