Name every derivation and generate the authority table #47

Parent

#35

What to build

Every derivation chapter 20 describes gets an identifier, its source features (in Project Intent, Platform Intent, the node contract, the locks or the ClusterState snapshot), its target feature in the Resolved Deployment metamodel, and its placed-by reading from chapter 20's authority rule. The rule set is the transformation's specification; no resolver is implemented here.

• The authority table is generated from the rule set and committed. It keeps its anchor, as 0004 requires ("the table lives once, at the normative anchor").
• Rendered kinds (the disruption budget, the monitors, the network policy set, the backup jobs) leave the authority table and appear as adapter outputs, so the table holds features only.
• The chapter's derivation prose cites rule identifiers.

Parity

The rule set is the specification both resolvers implement: the TypeScript resolver in src/ and the QVT-Operational transformation under emf/ (Task 2, due 2026-10-16). Each rule identifier is the name of the TypeScript derivation and of the QVTo mapping or helper that implements it, so a rule with no implementation on either side is found by name. Neither implementation is generated from the rule set, and the rule set is generated from neither.

Acceptance criteria

• Every authored feature and every Resolved Deployment feature is a source or target of some rule, or is listed with a reason.
• No target feature has two rules.
• The generated authority table regenerates without a diff, and hand-editing it fails CI.
• Every rule identifier is a plain name usable as a TypeScript function and a QVTo mapping name, and the rule set format states it.

Blocked by

• Declare the Project Intent metamodel once and parse every example with it #38
• Give the Resolved Deployment a metamodel and validate the worked projection #42