Support additional target notations

[Colinho22]

Motivation

Results are bound to a single target notation. Without a second, there is no way to tell which findings are properties of the orchestration and which are properties of the notation — which limits what any conclusion from the harness can claim.

Proposal

• Abstract notation-specific parts behind a plugin interface: prompt template, parser, validator, scoring matcher.
• Add a second notation behind that interface.
• Rerun the core design and compare findings across notations.

Done when:

• Notation is a plugin, not a branch in application code
• Second notation passes the existing control conditions
• Cross-notation comparison reported

Scope

• In scope: notation plugin interface, one additional notation, cross-notation comparison run.
• Out of scope: a third notation; notation-specific prompt optimisation beyond parity with the existing one.

Open questions

• Which second notation gives the most informative contrast — one structurally similar, which isolates surface syntax, or one structurally different, which tests generalisation harder?
• Does the second notation need independently authored ground truth, or is conversion from existing ground truth acceptable? Conversion is far cheaper but risks importing the first notation's structure.
• Is the scoring matcher genuinely notation-agnostic once relations are handled per Promote relation-level F1 to a first-class metric #93, or does each notation need its own matching rules?

Related

• Depends on Introduce orchestration modes: constrained pipeline and free-flow agentic #91 for the orchestration contract and on Promote relation-level F1 to a first-class metric #93 for the relation matcher.
• Largest item in the backlog; only justified if the harness continues as a research platform.