Catch broken relationships before writing the result
A proposal can have all the right fields and still refer to something that does not exist. Wildo pairs specification schemas with checks that understand the relationships inside each kind of artifact.
Generation can use the findings to correct an answer, and landing checks the content again. Checks across loaded product artifacts add context that a single document cannot provide.
Example — Connect a requirement to a real customer segment
A proposed requirement targets a customer segment that is absent from the loaded market snapshot. The cross-family check names the unresolved segment so the proposal can reference the intended audience. A segment reference that exists passes this check.
For engineers
The semantic binding first parses the stored schema, then runs the family’s validator. Errors and warnings have different effects. This source excerpt is the result mapping after successful schema parsing:
const result = input.runValidator(parsed.data);
const errors = result.issues.filter(input.isErrorSeverity);
const warnings = result.issues.filter((issue) => !input.isErrorSeverity(issue));
return {
validation: errors.length === 0 ? JourneyArtifactValidationState.VALID : JourneyArtifactValidationState.INVALID,
errorCount: errors.length,
warnCount: warnings.length,
errorDetails: errors.map((issue) => `[${issue.kind}] ${issue.path}: ${issue.message}`),
errors: errors.map((issue) => ({ kind: issue.kind, path: issue.path, message: issue.message })),
};
A schema error identifies a field or shape problem. Family findings can explain repeated references, inconsistent links or invalid relationships. The generation loop includes reported errors in its bounded correction attempts; a warning remains information to inspect.
Supply the context the check requires
| Check | Inputs it needs |
|---|---|
| Schema and family consistency | The candidate value and its registered binding |
| Cross-family dangling references | Loaded family values and accepted sibling outputs |
| Governed-document fact binding | The declared document facts |
| Required-document coverage | The application’s relevant document requirements |
A family validator called without optional external resolution sets cannot prove that every external reference resolves. The generation and landing paths have explicit cross-artifact helpers for supported relationships. A missing context input and an intentionally empty set are different conditions; callers must provide the application context they expect to validate.
Check the result that will actually be written
Landing validates the produced value before rendering. Where one produced document is merged into a document set, the merged result is also checked. The supported dangling-reference comparison overlays the candidate on loaded families and reports newly introduced citing-side references; it does not refuse every pre-existing inconsistency or every old reference orphaned by a legitimate replacement.
The broader coherence report remains useful after changes. These checks establish supported structural relationships, not whether a requirement is desirable or whether the implementation satisfies it. Those questions need review and execution evidence.