Shared domain logic has no home between the service crates and core

[LKSNDRTMLKV]

Domain logic needed by more than one service crate has nowhere to live in this workspace. Today the choices are: put it in dpp-core, or copy it. There is no third option, and copying is what happens.

The shape of the problem

dpp-common is the only crate every service reaches, and it is declared shared infrastructure — event bus, telemetry, mTLS, request-id, URL guards. It carries no dpp-domain dependency at all. Putting a regulatory predicate there would mean adding a core dependency to the crate that holds mtls.rs, which is a category error even when it compiles.

dpp-types is engine-wide data (operator config, auth, audit, API keys) and is not reachable from dpp-plugin-host.

So for logic that is about the domain rather than about deployment, and that two service crates both need, there is no legal home.

Why this is worth a decision rather than vigilance

Duplicated shapes are now handled: the OpenAPI contract test compares every published shape against the type behind it, and every_published_object_shape_has_a_name makes an unnamed one fail the build. A copied struct cannot drift silently.

Duplicated rules have no equivalent. There is no shape to compare — four copies of a predicate are four individually correct files. They compile, they pass, and they diverge the first time someone adds a condition to one of them. Nothing in CI can see it.

This has now happened three times in different forms:

• PROTECTED_PATCH_FIELDS restated and drifting three entries short of the canonical list, making protected fields writable on the only backend that ships.
• A query parameter spelled three ways across the description, the handler and a test, agreeing only by coincidence while the name was a single word.
• The live-passport-obligation test is restated in four places #208 — the live-passport-obligation predicate, written out in four places, which is the current instance and is being fixed by moving it to core.

The first two were shapes and are now gated. The third is a rule, and moving it to core is the right fix for that one predicate — but it is a fix per instance, not a fix for the cause. The next shared predicate will hit the same wall.

What to decide

Three options, roughly:

1. Everything domain-shaped goes to core. Consistent with the Golden Rule, and correct where the logic really is a statement about the law. The cost is that every such change becomes cross-repo: a core release plus a repin before the engine can use it. That is a heavy cycle for logic that is genuinely about how this engine gates, not about what the law says.

2. Add an engine-side domain crate that sits below the services and above dpp-common — a home for logic that is domain-shaped but is the engine's own policy rather than core's law. Cost: a new crate, and a boundary question on every future addition ("is this core's or ours?"), which is the question that is currently unanswerable and would at least become answerable.

3. Accept the duplication and rely on review. Cheapest today. The record above suggests it does not hold.

I would not decide this from inside a feature branch. Flagging it as the cause behind a defect class rather than proposing a fix.

Not urgent

Nothing is broken right now. All four copies of the #208 predicate agree, and that one is being consolidated into core. This is about what happens the fourth time, not the third.

[LKSNDRTMLKV]

Decision: option 1, with the boundary test stated as what makes it change rather than what it is about.

One correction to the premise first

There is a third option today, and it changes the shape of the problem: dpp-types already depends on dpp-domain. It is a legal home for domain-shaped logic right now — #232 uses it that way for snapshot_json_key, which is exactly "logic two service crates both need, about the domain rather than about deployment".

What it is not is universally reachable:

	crates
see dpp-domain	10 — dal, identity, integrator, node, plugin-host, render, resolver, seal, types, vault
see dpp-types	5 — dal, integrator, node, vault, cli
gap	identity, plugin-host, render, resolver, seal

So the question is not "is there a home" but "is there one reachable from every domain-aware crate", and only dpp-domain is. That is a structural argument for core, independent of taste.

And #208 lands squarely in the gap: one of its four copies is in dpp-plugin-host, which cannot see dpp-types. That instance genuinely cannot be solved engine-side without a new crate.

Why core is right for #208 specifically

!catalog.determinable_for(key).is_empty() && catalog.passport_required_for(key)

Both operands are core catalog accessors, thirteen lines apart in dpp-domain/src/instrument/catalog.rs (159 and 172). The predicate is a two-term composition of two neighbouring core methods over core data, with no engine input at all. It changes when the instrument catalog changes — that is, when the law changes. It is core's by the Golden Rule, not by preference.

Why not "everything domain-shaped goes to core"

That framing over-collects, and CLAUDE.md already has the sharper test. The Golden Rule asks what makes this change, not what is this about.

snapshot_json_key is domain-shaped — it is about passports — but it changes when the object-storage layout changes, which is operational. Under a literal "domain-shaped → core" reading it would move to core, which would be wrong, and would start eroding the Core Purity Rule from a direction that rule does not currently guard.

So the rule to record is not new policy. It is the existing one, written down as the answer to this question:

Shared logic goes to dpp-core when a change to the law is what changes it. It stays engine-side when a change to deployment, storage, or operation is what changes it. "Domain-shaped" is not the test — plenty of operational logic is about passports.

Engine-side shared logic goes in dpp-types, which already carries dpp-domain, for as long as its five consumers are enough.

The cost is lower than this issue assumes

It calls the cross-repo cycle heavy. The record: 12 core releases between 20 Jul and 27 Aug — roughly one every 3–4 days. Cadence is not the problem.

Coupling is, and it is visible today: core sits 3 commits past v0.19.0, unreleased for 6 days, on a feature branch. Anything the engine needs from core waits on that. Option 1 makes every shared predicate inherit that wait — a real cost, but a scheduling one, not an architectural one.

What this does not fix, stated plainly

• New duplication is still invisible to CI. That is this issue's central point, and moving one predicate does not address it. Four copies of a rule remain four individually correct files.
• There is no home for engine-side shared policy that plugin-host, render, resolver, seal or identity need. If such a case appears, we are back here — but with the boundary question now answerable, which it is not today.

The second is hypothetical. Building the crate pre-emptively is the mistake already recorded once in this workspace: a split with no beneficiary. Let a real counter-example argue for it.

Next steps

1. Move the predicate to dpp-domain beside its two operands, under one name — passport_obligation_live and passport_determinable currently mean the same thing under different names, which is its own tax on a reader checking whether the gates agree.
2. Release core, repin, delete all four copies in the same change so they cannot be half-migrated.
3. Record the boundary test above where the next person will look.

Blocked on a core release, so it sequences behind whatever is holding v0.20.0.