Repository navigation
File Platform Intent as the platform description model #52
Description
Parent
What to build
Project Intent is the platform-independent model, and its enumerated fields are the marks that select a derivation. Platform Intent and the node contract are the platform description model. Resolution weaves the two. The chapters say so, and chapter 00's substrate-swap claim covers Project Intent only: Platform Intent names CRD API groups and a CNI by design.
Chapter 14 states one rule for where a vocabulary lives: fixed in the metamodel when derivations branch on its values, defined by the platform when only the platform gives it meaning, with every reference from Project Intent checked as an invariant.
Settled in this ticket: 0076 is reopened. A tier names its forward-auth endpoint as an Application, a surface and a path, resolved like a dependency edge, instead of a cluster-DNS URL that restates the authenticating Application's namespace and port. Chapter 20's forward-auth section and the worked Platform document change with it.
Decided inside this ticket, under the rule above: whether Engine and AlertClass move to platform-defined vocabularies, and what happens to the valkey engine value, which no valid document can use today (an engine is refused where no backup derives, and the Platform engines map has no valkey entry).
Parity
Moving Engine or AlertClass between a metamodel enumeration and a platform-defined vocabulary is a metamodel change in both implementations: the Zod schemas, the Ecore packages, the descriptor and the affected intent.json and diagnostics.json oracle files change in the same pull request, and both implementations stay red until both match.
Acceptance criteria
- No authored document carries a cluster-DNS name.
- A tier whose forward-auth reference names an unknown Application or surface fails with a code.
- 0076 carries the amendment, and 0095 cites the vocabulary rule.
- Every enumeration value can appear in some valid document.
- The descriptor and the affected oracle files change in the same pull request as the vocabulary decision.
Activity
docs: state where a closed vocabulary's literals live (#125)
ExtraToast commentedon Sep 16, 2026
Parked, with the documentation half landed in #125.
Chapter 14 now states where a closed vocabulary's literals live, and applies the rule to the two this ticket asks about:
Enginestays fixed because a derivation branches on the literal,AlertClassstays fixed because it is the Application's own authored claim for a reader past the model's edge. ADR 0095 cites the new section. Nothing moved, so no code, schema, descriptor or oracle changed.What is left needs a model change in both implementations, landed together with its oracle files per the parity contract:
forwardAuthstill carries a cluster-DNS URL in chapter 14, the worked Platform document and its oracle, and both parsers read it as a plain string. It becomes a reference to an Application, a surface and a path, refused with a code when it does not resolve.Engine::valkeyappears only in a refusal fixture, because the Platform'senginesmap assigns it no policy. It either gains one, with a Process that uses it, or leaves the vocabulary. Either way the generated vocabulary table, the descriptor and both enums change.Unclaimed and waiting on the model's design settling, rather than in progress.
ExtraToast commentedon Oct 1, 2026
Unblocked: #41 and #26 are closed. Note from the 2026-10-01 delivery decisions (#195): the Platform document moves into JorisJonkers-dev/estate (JorisJonkers-dev/estate#1), so its home in this ticket is the Estate repository.
ExtraToast commentedon Oct 9, 2026
Folded into the rewrite plan by Decide the fate of the open work that predates the map; its residue is listed on that ticket's resolution, which
/to-specreads when the map (#341) clears.