Use AI for judgment. Make the checks explicit.

AI helps explore a product, write its definitions and implement its behavior. Wildo connects that work to structured contracts, repeatable checks and reviewable changes, so a convincing answer is the beginning of evaluation rather than its conclusion.

The problem it answers

An answer can sound right while naming a requirement that does not exist, overlooking a business rule or producing code that does not compile. Asking another model whether it looks good cannot replace checking those properties directly.

Different questions need different kinds of evidence. A schema can check structure; a validator can check declared relationships; a build can check TypeScript compatibility. Understanding whether the result serves the product still calls for judgment and testing.

What it rules in, and what it rules out

Wildo gives each kind of evaluation a defined role. Structured generation uses the artifact’s schema. Validation findings tell the next attempt what to correct. Product review considers authored criteria and the evidence available. Git keeps the resulting changes inspectable.

These roles work together without becoming interchangeable. Passing validation does not establish market demand. A positive review does not prove runtime behavior. Declaring an agent’s permission profile does not establish that every tool it runs is confined to a filesystem boundary.

What it means for someone building with Wildo

You can use model judgment where interpretation adds value while retaining concrete checks for the properties the framework knows how to evaluate. Read the findings, inspect the changes and test the behavior that matters to your application.

Acceptance remains a separate decision from generation or review. Wildo’s autonomy policy distinguishes human acceptance in guided work from automatic acceptance in its more autonomous modes. The author of an edit and the authority accepting it are separate roles; a model’s favorable assessment alone does not collapse them into one.

For engineers

Where it lives in the framework

Generation carries a contract and a correction loop

runPlaybookGeneration resolves each output’s semantic binding before calling the generation provider. The provider receives the generation schema when the binding supplies one, otherwise the snapshot schema. A generated value is normalized where needed and passed through binding.validate before it is accepted for landing.

This excerpt shows the validation handoff inside that loop:

let candidate: unknown;
try {
  candidate = binding.generation
    ? binding.generation.normalize(generated.output, { recordedAt, nextReviewOn: input.nextReviewOn })
    : generated.output;
} catch (error) {
  const findings = error instanceof z.ZodError
    ? error.issues.slice(0, 20).map((issue) =>
        `${issue.path.map(String).join(".") || "<root>"}: ${issue.message}`)
    : [error instanceof Error ? error.message : String(error)];
  rejectedFindings.push(findings.join("\n"));
  accepted = undefined;
  continue;
}
const validation = binding.validate(candidate);
if (validation.validation === JourneyArtifactValidationState.VALID) {
  // The generation loop evaluates its applicable cross-family checks next.
}

The final comment abbreviates the following source branch; this is a runtime excerpt, not an application configuration to paste. The loop also feeds provider rejections and validation findings into later attempts. The default is three attempts per output, configurable with maximumAttemptsPerOutput.

Cross-family checks depend on the context supplied to the run. For example, declaredDocumentFacts being absent skips that check; an empty map actively checks against an empty declared set. When landedFamilyValues is provided, candidate reference checks include accepted sibling outputs from the same run. This makes the supplied context part of the validation contract, not an optional detail behind a universal correctness claim.

Review has a different job from validation

The post-generation playbook judge evaluates landed values against authored criteria. Its response uses a constrained verdict vocabulary, omitted criteria become indeterminate, and the overall result follows the least favorable criterion. That judge is advisory: its failure produces a skipped result rather than undoing the generation run.

Context review is a separate mechanism. A playbook can opt into briefAdequacyGate; the companion asks whether its generation brief needs more context and may recompose it once with additional permitted source categories. Existing sources remain, excluded sources remain excluded, and an unavailable judgment leaves the original brief in use. This is a bounded context repair, not a standing model that rewrites the coding task’s rules.

buildApplicationCoherenceReport provides another view over the loaded specification families: cross-family findings and coverage questions that a single artifact cannot answer alone. Its report helps direct follow-up work; it does not turn every finding into a refusal to proceed.

Check the actual execution boundary

For an ACP coding run, the host answers permission requests and can check paths supplied by those requests or host-mediated file callbacks. Those checks depend on the adapter using those protocol channels. A shell command without declared locations is not a path-confined operation, and direct file access that bypasses both channels is not covered by their predicates.

The practical review therefore includes the selected adapter’s behavior, the workspace changes, the requested checks and their results. A compilation result answers a narrower question than an application test or a live user journey. Keep that distinction visible when accepting work.