Validate correction repair through the processing command
This commit is contained in:
@@ -16,7 +16,13 @@ credential source names for artifact redaction without inspecting unrelated
|
||||
environment values. See the [integration contract](../integrations/openai-compatible-llm.md)
|
||||
for failure behavior and the [configuration reference](../config.md) for sources.
|
||||
|
||||
Proposal calls can retain the original prompt, effective variables, prepared messages, and final response for section-local repair replay. The adapter renders the repair definition with the selected profile, appends branch history to the original prompt, and checks the prepared prefix before execution. The requested repair definition is retained in call attribution alongside the native base-prompt metadata.
|
||||
When correction repair is enabled, the proposal call retains its prompt,
|
||||
effective variables, prepared messages, and full final response for section-local
|
||||
replay. The adapter renders the repair definition with the selected profile,
|
||||
appends only that branch’s history, and checks the original prepared prefix
|
||||
before execution. The complete conversation is sent to the selected provider;
|
||||
provider rejection ends that branch as unavailable. The requested repair
|
||||
definition is retained in call attribution alongside native base-prompt metadata.
|
||||
|
||||
The observation collector tracks logical calls and execution events. Ordinary
|
||||
reports use compact safe outcomes; request and response evidence is optional
|
||||
|
||||
@@ -13,6 +13,9 @@ Modules implement `contracts.TranscriptModule`:
|
||||
- `Validators()`
|
||||
- `Propose(ctx, req)`
|
||||
|
||||
Built-in modules also expose `RepairPromptID()` for the runner to select their
|
||||
repair definitions; proposal-only callers retain the existing interface.
|
||||
|
||||
Runner resolves configured module specs to module instances through `internal/framework/modules`.
|
||||
|
||||
## Built-In Modules
|
||||
@@ -61,6 +64,10 @@ Module packages call the built-in chain resolver at construction.
|
||||
|
||||
## Failure and Outcome Behavior
|
||||
|
||||
Each actionable rejection can be revised or withdrawn within its original
|
||||
section. A revision retains the original proposal identity and must pass the
|
||||
full validator chain before application.
|
||||
|
||||
Module construction failures are fatal. Recoverable proposal model failures
|
||||
record an unsuccessful operation and yield no candidates for that section;
|
||||
other sections and module instances continue. Fatal adapter or application
|
||||
|
||||
@@ -11,9 +11,10 @@ and `audita/modules.grammar.proposal`; the corresponding repair IDs replace
|
||||
|
||||
PromptKit composes embedded defaults with operator prompt sources. Shared
|
||||
instructions come from the embedded fragments in `assets/shared`; the request
|
||||
adapter fills absent `HardeningPolicy`, `ProposalContract`, `RepairContract`, and
|
||||
`ValidationContract` variables without replacing values explicitly supplied by
|
||||
the caller. Processing supplies Audita's response-schema contract separately.
|
||||
shared-variable helper fills absent `HardeningPolicy`, `ProposalContract`,
|
||||
`RepairContract`, and `ValidationContract` variables. The processing adapter
|
||||
supplies the embedded instruction fragments for those names. Processing supplies
|
||||
Audita's response-schema contract separately.
|
||||
The operator's prompt definition controls which variables its template uses.
|
||||
|
||||
For a standard request preview or validation, select a native PromptKit profile
|
||||
@@ -23,7 +24,10 @@ proposal definitions use `TranscriptDescriptionBlock`, `GlossaryJSON`,
|
||||
and the separate spelling list defines protection. Preview defaults the
|
||||
spelling list to `[]` when omitted. The validator definitions use `TranscriptDescriptionBlock` and
|
||||
`PayloadJSON`. The latter is supplied candidate JSON and does not require a
|
||||
proposal inference call. An operator replacement may use different variables.
|
||||
proposal inference call. Repair definitions use `RepairContract` and
|
||||
`RepairRequestJSON`, containing the original proposal reference, current
|
||||
correction, and ordered findings. An operator replacement may use different
|
||||
variables.
|
||||
See the [upstream CLI reference](https://forge.maximumdirect.net/base-layer/commandkit/src/commit/f369d6a78253b6e6fcb1e023fb2e9c3af1d20ff0/docs/cli.md)
|
||||
for the standard preview, validation, and smoke commands.
|
||||
|
||||
|
||||
@@ -49,7 +49,10 @@ For each module section:
|
||||
When correction repair is enabled, the runner also gathers independent findings
|
||||
for rejected candidates when a validator has usable evidence. Unavailable
|
||||
assessments remain unavailable, and only candidates that pass every applicable
|
||||
check can advance. A zero repair budget retains the original shortlist flow.
|
||||
check can advance. A known rejection can enter repair even when another
|
||||
assessment is unavailable; an unavailable assessment alone does not. Revised
|
||||
candidates run the applicable checks again. A zero repair budget retains the
|
||||
original shortlist flow.
|
||||
|
||||
Decision cardinality is enforced inside Audita: each candidate proposal must
|
||||
receive exactly one outcome per validator it reaches. The runner still rejects
|
||||
|
||||
Reference in New Issue
Block a user