Validation defines whether an Attestor object satisfies Attestor's applicable normative structural and rule requirements.
Validation determines whether an object is correctly formed and governed according to Attestor architecture. It does not determine whether an Attestation is true, whether a Trust Statement is favorable, or whether the underlying evidence is sufficient.
Validation determines whether an Attestor object satisfies the normative structural and rule requirements applicable to that object. It answers whether the object is correctly formed and governed according to Attestor architecture—not whether its assertion or conclusion is true.
Validation applies to Attestor-owned objects and their governed representations. Different object classes may have different required structures, controlled values, relationships, provenance requirements, lifecycle constraints, and rule checks.
Structural validation tests whether required information is present, correctly represented, internally coherent, and compatible with the applicable object schema or profile.
Semantic validation tests whether controlled values, identifiers, object roles, relationship meanings, authority context, provenance modes, lifecycle states, and other governed semantics are used consistently with Attestor architecture.
Rule validation tests applicable normative Attestor requirements derived from established principles, rules, and architecture. A structurally complete object can still fail validation when it violates a governing rule.
Relationships must use permitted meanings and, once formalized in Schemas, permitted source/target combinations and cardinalities. A syntactically present relationship is not valid merely because it can be serialized.
Validation checks whether lifecycle and version information is internally consistent with the object's identity and governed history. It must not allow versioning or lifecycle metadata to conceal a new canonical object or erase a prior governed state.
Validation produces a governed validation determination for the object or representation tested. Per-rule results are pass, fail, not-applicable, and not-tested; aggregate results are valid, invalid, incomplete, and error. NOT-TESTED never equals PASS.
Attestor validation is layered because correctness is more than file syntax. An object may be machine-readable yet still violate semantic, relationship, lifecycle, provenance, or institutional rules.
Validation must trace back to adopted Attestor architecture rather than inventing requirements inside a validator. Principles guide the institution; Rules constrain behavior; normative requirements formalize those constraints; validation tests them.
Attestations and Trust Statements are distinct canonical objects and therefore require distinct validation profiles. Shared foundational requirements may be reused, but each object class must be validated according to its own role and structure.
Validation may test whether the required evaluation context is represented and internally coherent—for example, whether a Trust Statement is traceable to an evaluation basis and applicable Attestation. Validation does not rerun the substantive evaluation merely to decide whether the resulting conclusion should have been supported, contradicted, or indeterminate.
Validation may confirm that an object records required eligibility context and uses governed eligibility rules correctly. It does not convert every referenced input into an eligible input. Eligibility remains an evaluation-specific governed admission determination.
A validation failure identifies a failure to satisfy an applicable normative requirement. Failures must be attributable to identifiable requirements and sufficiently specific to support correction. Validation must not use vague failure states to conceal which rule was violated.
An invalid Attestor object may require correction, but the correction path depends on materiality. A structural or bounded metadata defect may be corrected within the same canonical identity when Versioning permits. A correction that changes essential institutional meaning may require a new canonical object and supersession.
Validation and Conformance are related but distinct. Validation asks whether a particular Attestor object satisfies its applicable normative requirements. Conformance asks whether an object, implementation, producer, or process meets the declared Attestor specification or profile requirements applicable to it.
A valid object is not automatically published. Publication is a separate governed decision about public representation. Likewise, publication must not be treated as proof that an object has passed every applicable validation requirement unless the publication rules explicitly require that condition.
The Validation architecture is implemented through normative Validation Requirements, the numbered VAL-* Rule Catalog, machine contracts, executable schemas, and versioned validator software. Validator v0.5 is the operative production validation endpoint.
Validator v0.5 was exercised against the first canonical production Attestation and Trust Statement and again against their final Active · Published representations. Both final production objects returned VALID with zero mandatory requirements left not-tested.
Validator v0.5 preserves the distinction between deterministic validation and genuinely review-dependent requirements. A Review-bound rule may remain not-tested in machine execution when nonmandatory for the aggregate result; that status is not silently converted into a pass. The first production operation separately completed governed Review with 25 / 25 requirements SATISFIED.
Validation is a normative compliance determination. It does not independently establish truth, authority, eligibility, evidence sufficiency, evaluation outcome, publication, or institutional conformance.
Validation is no longer only conceptual or pre-production. The architecture has been translated into executable rules and report semantics, exercised through Validator v0.5, and proven against the first canonical production Attestation and Trust Statement.
Production validation of ATT-2026-0001 and TRST-2026-0001 establishes a first-production baseline. It does not make future objects automatically valid; each future object must independently satisfy its applicable normative requirements.
Back to Attestor →