Status
This document owns the permanent reasoning and artifact contract for LLM authoring. It is not a substitute for the generated wire-format authority. Current generated schemas and SDKs project the implemented PF-01/PF-02 typed condition, acquisition-binding, evidence, and pure-evaluation representation. PF-09 still owns final product fixtures, packaging, release evidence, and human approval.
Required artifact graph
An authoring agent produces reviewable hostile syntax for:
claim inventory
-> typed condition definitions
-> evidence-use policies
-> separate acquisition bindings
-> stage RET completion laws
-> Xarxa prerequisite laws
-> explicit scenario completion law
-> bounded raw scenario specification
DG, not the LLM, admits those artifacts through sealed constructors. The agent cannot assert that a graph, predicate, provider relation, evidence item, stage, or scenario is valid merely by labeling it so.
Authoring rules
- State the operational claim in falsifiable language.
- Define each condition independently of its acquisition path.
- Select a closed observation domain and comparator-specific predicate.
- State exact evidence-use facts, including freshness, integrity, authorization, source, scope, and retention requirements.
- Add only selected acquisition paths. Caller submission needs no fake provider; network/subprocess paths are excluded initially.
- Compose stage truth with full satisfiable RET.
- Compose topology only with monotone prerequisite RET consumed by Xarxa.
- State an explicit monotone scenario completion law. Leaves are not implicit success.
- Attempt to falsify predicates and identify unknown feasibility rather than claiming liveness.
- Submit hostile syntax and preserve every typed admission failure.
Execution contract
The harness, not the scenario graph, decides which ready stage to open or how many agents work concurrently. Opening one stage neither assigns an agent nor cancels a sibling.
Evidence enters through source-specific acquisition, admission, and
condition-use-policy witnesses. Pure evaluation consumes only a canonical
admitted-evidence snapshot and performs no I/O. Operational acquisition failure
mints no semantic proposal. Semantic True, False, and Unknown are derived
only from valid admitted resolutions.
The accepted-run authority then decides whether the candidate becomes history. A stale candidate mutates nothing. An accepted intent is not an external effect.
Caller evidence
An agent may submit bounded material. That proves only that the attributed caller submitted the material under the recorded request/context. The agent cannot self-assign source authority, integrity, freshness, independence, absence, comparator status, or trust. Other facts require independent witnesses.
Initial profile
Selected acquisition families are caller submission, named time observation, allowlisted immutable environment snapshot, and rooted JSON/YAML observation. HTTP/REST, remote MCP, MCP stdio/subprocess, arbitrary executable providers, remote evaluation, and attested/custom execution are not initial capabilities.
Verification and nonclaims
The authoring package must preserve exact law, graph, condition, policy, binding, evidence, run, stage, and accepted-head identities. Verification reports separate structural validity, content integrity, evidence admission, semantic replay, accepted-history integrity, dispatch status, external binding, deployment qualification, and release provenance.
An LLM-generated scenario passing its own predicates does not prove the predicates express operator intent. Independent review and adversarial falsification remain required before consequential use.
Current executable guidance
Current tool names and wire fields remain authoritative only through generated current-contract documentation. They must not be copied into new permanent standards or preserved through compatibility aliases. PF-01/PF-02 authoring and evaluation are executable; an end-to-end supported product claim remains blocked on PF-06A formal dispatch closure, PF-06B/PF-06C local implementation and refinement, PF-06D/PF-06E platform integration, PF-07/PF-09 qualification, and release closure.