What is goal-grounded generation?
Goal-grounded generation is a way of calling a model where the input includes an explicit mission, the relevant slice of a project context graph, and the acceptance criteria the output will be evaluated against. The model is generating against a defined goal and a known evaluator, not just answering a free-text prompt.
Definition
A goal-grounded generation call has four parts: the mission (what we're trying to accomplish), the context (what the system already knows), the constraints (what must be true), and the acceptance criteria (how the result will be judged). The model sees all four and produces a candidate aligned to them.
Why it matters
Most quality failures trace back to context loss: the model didn't know the goal, didn't have the right context, or wasn't told what 'done' looked like.
Goal-grounded generation closes the loop between generation and evaluation — both stages see the same criteria.
How it works
- The orchestrator pulls the mission record for the current step.
- A context resolver selects the relevant subgraph from the project's context graph.
- Constraints and acceptance criteria are attached to the call.
- The model generates a candidate, knowing exactly how it will be judged.
- Gates evaluate against the same acceptance criteria the model was given.
Example
Instead of 'write a release note for v2.1', the system passes the v2.1 mission, the shipped PRs, the user-facing changes, the brand voice, the forbidden-claims list, and the acceptance criteria (must mention every user-facing change, must be under 200 words, must link to docs). The model writes against that, and the gate scores against the same criteria.
Cyryx perspective
In MAAX Studio, every generation call is goal-grounded by default. The mission, context graph, and acceptance criteria are first-class objects in the runtime, not strings someone remembered to paste into a prompt.
This is the lens Cyryx Labs applies across MAAX Studio, Cyryx Solutions, and the Cyryx Applied AI Lab.
Metrics to track
- Acceptance-criteria coverage — fraction of criteria explicitly addressed in the output.
- Context resolution recall — did the resolver include the inputs the model actually needed?
- Regeneration rate — falls as grounding improves.
- Drift between criteria the generator saw and criteria the evaluator scored — should be zero.
Common mistakes
- Letting prompts and acceptance criteria evolve independently.
- Stuffing the full project into context instead of resolving the relevant slice.
- Treating retrieval as grounding without carrying the goal forward.
- Re-prompting on failure without updating the context the model saw.
Frequently asked questions
Is this just better prompting?
No. Prompting is one input. Goal-grounded generation also supplies the mission state, the relevant slice of a context graph, and the acceptance criteria the output will be evaluated against.
Does it replace RAG?
It uses retrieval, but retrieval alone is not goal-grounded. RAG fetches relevant text; goal-grounded generation also carries goal, constraints, and acceptance criteria into the call.
Why does the acceptance criteria need to be in the prompt?
Because the same criteria are used by the evaluator gate. Putting them in the prompt aligns generation and evaluation against one shared definition of done.