Retire assembly origins on object.value (one spelling of derived read shape) — RULED: batch into the pre-1.0 consolidation

[dmealing]

Summary

There are currently two spellings of "derived read shape": object.projection (+ origin.*, the SQL/read-model path) and object.value (+ origin.*, used for FR-004 prompt/template payloads). FR-024 §1 states outright that these arose "by accident of which feature shipped them," migrated one (entity+extends+view), and spared the other. The value spelling is a grandfathered compatibility spelling, not a principled category — and it leaves a permanent "why are there two?" seam every adopter re-asks.

The principled boundary (direction of data flow)

• Projection = system-PRODUCED output. Derived from the entity graph, read-only at the subtype level, optionally addressable (borrowed identity ⇒ get-by-id) and/or materialized, referenced as an operation's outputRef.
• Value = caller-CONSTRUCTED input / embedded shape. Command inputs, proc args (@parameterRef), embedded VOs whose storage belongs to the owning entity's field. Never populated, never sourced, never keyed; content equality.

A payload the framework assembles from Author.name + count(posts) + a nested collection is system-produced derived output — a projection by every test above. Calling its assembly "construction" stretches the population doctrine past usefulness (templates-and-payloads.md notes the payload codegen path is already shared with the projection path).

Proposal (pre-1.0, within ADR-0035's window)

• Retire origin.* on object.value.
• Let template.* @payloadRef accept sourceless projections.
• Nested payload shapes become sourceless projections reached by origin.collection.

Then value purity becomes total — no identity, no source, no origins — so the value rule regime is trivially checkable (child-licensing, not conditional rules), and the ecosystem has exactly one spelling of "derived read shape."

Cost / benefit

Payload-VO codegen paths + conformance fixtures churn across 5 ports — but mostly node-type relabeling, since the payload path already shares the projection codegen path. Benefit: the projection/value boundary stops being a recurring question, and "value" becomes a clean, total-purity category. If the churn is declined, the fallback rule of thumb ("origins on a value are legal only inside template-payload assembly; any top-level, independently addressable derived read shape is a projection") leaves the seam permanently.

[dmealing]

Ruling (2026-08-05): DO IT — but not yet, and not as written

Trigger: the close of the Phase-1 feedback window, landed as part of the single pre-1.0
breaking-consolidation batch. Never as a standalone release. If nothing else breaking has
surfaced within ~90 days of the launch, it ships alone as that batch.

Scope — narrower than the original proposal

The proposal above retires all origin.* on object.value. That is broader than the doctrine
the loader already encodes, and broader than the seam actually justifies.

• Retire the ASSEMBLY origins on values — origin.aggregate, origin.computed,
  origin.collection, origin.first become illegal on a value-hosted field (a new
  ERR_SUBTYPE_RULE_VIOLATION case).

• Keep origin.passthrough on values. FR-015 parameter VOs (source.rdb @parameterRef)
  stay exactly as they are. The loader already draws this line —
  validation-passes.ts validateOriginPaths:

  FR-024 B5: object.value hosts are EXEMPT from @via inference and cardinality checks —
  a value's origin.passthrough is FR-015 parameter lineage (values are constructed,
  never assembled; spec §7), not an assembly path.

  A proc arg is caller-constructed input; routing it through object.projection would violate
  the direction-of-flow principle this issue itself invokes. Retiring its lineage would also
  silently drop the _checkPassthroughType / ERR_PASSTHROUGH_TYPE_MISMATCH type-preservation
  check on proc args — a real regression, not a cleanup.

• Widen @payloadRef / @responseRef to accept an object.projection carrying zero
  source.* children. Today this is a hard check on OBJECT_SUBTYPE_VALUE
  (validation-passes.ts, gated by fixtures/conformance/error-template-payload-ref-not-value,
  whose meaning flips).

• No new vocabulary required. origin.collection is already registered (required @via),
  and a sourceless projection loads legally today — validateProjectionLicensing has no
  source-required rule and validateDerivedFieldProvidability exempts projections. This sits in
  the ADR-0046 / Non-persisted shapes (messages/DTOs) can't declare field-level references to entities #238 cost class: a child-licensing + validation-rule change.

• But expected-registry.json DOES change. object.value's rules string reads
  "constructed — by a caller, by assembly, or by embedding". That string is byte-checked, so
  all five ports' embedded definitions sync in lockstep.

Drop the "total value purity" framing. It was never achievable: ADR-0046's @enforce: false
navigation-only reference already made value rules conditional, and parameter lineage keeps them
so. The post-ruling rule is better because it is subtype-scoped rather than context-scoped:

Passthrough on a value is lineage. Assembly origins live on projections.

Why do it at all

1. Near-zero usage, and that only worsens. A scan of every conformance fixture, the
   examples/ tree and the public reference app found a handful of fixture dirs and one teaching
   example (examples/advanced-modeling ProgramDescriptionPayload). The reference app — the
   heaviest prompt-pillar consumer, 18 files of payload VOs — uses zero. Migration cost is at
   its historical minimum.
2. This is a live behavioral divergence, not a prose seam. Payload-origin handling already
   differs across ports: Kotlin (KotlinPayloadGenerator) and Python (payload_vo_generator)
   resolve origins for payload field typing; TS and C# are origin-blind; Java carries a standing
   KNOWN_GAPS deferral. It is only benign because verify: origin.passthrough field type must match its source unless an explicit transform is declared #185's ERR_PASSTHROUGH_TYPE_MISMATCH makes
   origin-derived typing redundant with declared typing. That debt gets paid either way — finished
   in five ports, or retired in five. Retiring is strictly cheaper and deletes the open question.
3. Declining does not avoid the cost, it defers it into a post-1.0 world where it becomes a
   Metamodel 2.0 event.

Why not now

"Mostly node-type relabeling" is half true. Fixture churn is trivially small. The code churn
sits in the payload tier — this repo's recent cross-port bug hotspot (ADR-0044 #219/#220 took
three stages; #228 found the extract tier resolving payload refs package-blind, both latent behind
green suites). The riskiest piece: every port's projection fan-out must cleanly no-op on a
sourceless projection, and #248 ("persistability derives from a declared source.*") shipped
npm-only, so four ports have never seen one.

Honest estimate: comparable to #228 plus a breaking loader rule — a 1–2 week focused effort with
the no-mistakes gate, with the real risk concentrated in the four non-TS ports' dispatch rather
than in diff size. That is not work to discover during a launch that showcases the prompt pillar.

Sequencing

1. Phase-1 launch ships first, untouched, on 0.20.x.
2. During the feedback window, land two free, non-breaking preludes that de-risk the real
   work (filed separately, both blocking this issue):
   • delete the redundant Kotlin/Python payload origin-typing and close Java's KNOWN_GAPS
     entry as moot (output-identical post-verify: origin.passthrough field type must match its source unless an explicit transform is declared #185);
   • port Persistability is decided by a hardcoded subType === "value" compare — any custom object subtype silently becomes a table #248's persistability-from-source contract cross-port.
3. Then this rides the one pre-1.0 consolidation batch, before any quiet-period declaration.
   ADR-0035 §3: a breaking move during the run-up restarts the quiet-period clock, so it must be
   batched, and it must land while 1.0 remains unscheduled — which it explicitly is.

What would reverse this ruling

• Phase-1 feedback showing real adopters authoring assembly origins on payload VOs. Each one
  raises migration cost and argues the pattern is loved rather than vestigial; more than a couple
  → decline and document the rule-of-thumb instead.
• The Persistability is decided by a hardcoded subType === "value" compare — any custom object subtype silently becomes a table #248 prelude revealing that any port's projection fan-out cannot cleanly no-op on a
  sourceless projection without new vocabulary (e.g. a marker distinguishing a wire-assembled
  projection from a DB one). New vocabulary is a different cost class under ADR-0023 and reopens
  the call.
• 1.0 being scheduled imminently off strong Phase-1 signal. Then the seam is not worth restarting
  the clock: ship 1.0, document the rule-of-thumb, and let this be a 2.0 candidate.

[dmealing]

Preludes filed and blocking this issue: #270 (retire redundant payload origin-typing in Kotlin/Python, close Java's KNOWN_GAPS entry as moot) and #271 (port #248's persistability-from-source contract cross-port; prove each fan-out no-ops on a sourceless projection). #271 also carries the falsification signal — if any port needs new vocabulary to handle a sourceless projection, it reopens this ruling.

[dmealing]

Batch scope note: the pre-1.0 consolidation batch this issue rides now also carries the @role registry change from #212 — removing publish from source.rdb @role's allowedValues (live in expected-registry.json, spec/metamodel/db.json, and five ports' embedded definitions), and possibly the wider shrink to primary | replica pending the sub-decision recorded there. Same class as this issue's object.value rules-string change: lockstep across five ports, technically breaking, zero fixtures affected. Batching them means one window, one review.

[dmealing]

Batch scope, updated: the @role change riding this batch is now the full shrink to primary | replica (ruled on #212), not just the publish removal. Cross-port verification closed the gate — every read of @role in all five ports is an equality test against primary; Java OMDB has zero role usage, and Kotlin/Python's write-through read paths are explicitly documented "role-agnostic" (they find the replica by @kind). index/cache/publish/mirror become reserved-not-registered per the ADR-0040 precedent. One pre-landing check inherited from that ruling: these are shipped registered members, so re-run ADR-0036's adopter scan plus the public reference app before removing them — zero uses were verified in this repo only.