| name | cto-build-framework-validator |
| version | 1.1 |
| description | Validate CTO Build Framework governance artifacts and file version-bound evidence (runs, reviews, evidence packets) without inflating claims. Use for independent re-execution, internal-consistency reviews, and verdict filing. |
| trigger | governance validation, framework validation, evidence packet, compliance check, proof doctrine, independent re-execution, validator verdict |
| status | active |
| updated | "2026-04-25T00:00:00.000Z" |
CTO Build Framework Validator
Repo-local skill for governance validation work that must be evidence-bounded and reproducible. The framework's principle is that the system that builds the software cannot be the sole auditor of it.
Core Objective
Produce filed, version-bound validation artifacts from the framework SSOT:
- run execution records
- review verdicts
- evidence packets
- explicit proof limits
Non-Negotiables (Proof Doctrine)
- Only claim what evidence supports.
- Do not change domain status labels unless explicitly authorized by the framework owner.
- Evidence must be version-bound (commit/version + environment + date).
- Treat independent re-execution as a separate validation mode from artifact-only review.
Doctrine sources (read these once before first review)
governance/audit-separation.md — why builder ≠ auditor
governance/core-loop.md — six-phase governance cycle
governance/release-gates.md — what a release requires
governance/llm-operating-discipline.md — operating constraints for AI-driven validation
governance/dev-auditor-protocol.md — auditor scope and limits
governance/rollback-protocol.md — when to revert
governance/ui-validation-protocol.md — UI evidence requirements
Canonical Entry Points (Read First)
- Operator entrypoint:
kb/ROLE-ENTRYPOINTS.md § Validator
- Artifact map (quick):
kb/ARTIFACT-MAP.md
- Repo state snapshot:
validation/project-closeout-index.md
- Domain truth:
validation/domain-matrix.md
- Run traceability:
validation/validation-run-index.md
- Evidence roadmap / change-control:
validation/evidence-expansion-roadmap.md
Validation Modes
1) Independent Re-Execution
- Identify the target run in
validation/validation-run-index.md.
- Execute the corresponding checklist under
validation/runs/ with no skipped items.
- File a completed verdict under
validation/reviews/ using the templates below.
- Attach or reference artifacts (screenshots/logs) per the run's acceptance criteria.
- State execution environment, commit/version, date/time, and operator identity.
2) Internal Consistency Review (Artifact-Only)
- Open the evidence packet under
validation/evidence-packets/.
- Confirm each claim is bounded and traceable to referenced artifacts.
- File reviewer verdict under
validation/reviews/.
- Explicitly mark the mode as
artifact review only (not independent re-execution).
Templates by Step
| Step | Template (in validation/templates/) | Output destination |
|---|
| Record a re-execution run | domain-validation-run-template.md | validation/runs/{domain}-{project}-{date}.md |
| Record a domain-level result | domain-validation-result-template.md | validation/runs/{domain}-{project}-result-{date}.md |
| File reviewer verdict | reviewer-verdict-template.md | validation/reviews/{domain}-{project}-review-{date}.md |
| Build evidence packet | evidence-packet-template.md | validation/evidence-packets/{domain}-{project}.md |
| Wrap reconstructed-app run | reconstructed-run-wrapper-template.md | validation/runs/{domain}-reconstructed-{date}.md |
| Non-coder operator | non-coder-operator-checklist.md | validation/runs/... |
| Simulation log | simulation-log-template.md | validation/simulations/... |
Filename Convention
- Runs:
{domain}-{project}-{YYYY-MM-DD}.md
- Reviews:
{domain}-{project}-review-{YYYY-MM-DD}.md
- Evidence packets:
{domain}-{project}.md (no date — the packet is the canonical proof record)
- Independent re-execution artifacts: prefix with the run id (e.g.
AUTH-1-...)
Required Output Contract
Every filed verdict must include:
- validation mode:
independent re-execution or artifact review only
- scope: what was verified and what was not
- status per item:
PASS, FAIL, or NOT TESTED
- version bound: commit/version, environment, date
- evidence pointers: artifact paths or links
- operator identity: name + relationship to builder (independent / founder / contributor)
- claim discipline statement: no evidence, no claim
Worked Example: AUTH-1
The AUTH-1 (auth-authorization) re-execution chain is the canonical example. When in doubt about format or rigor, mirror AUTH-1.
- Request packet:
validation/runs/AUTH-1-independent-reexecution-request-packet.md
- Operator handoff:
validation/runs/AUTH-1-independent-operator-handoff.md
- Re-execution checklist:
validation/runs/AUTH-1-independent-reexecution-checklist.md
- Founder verification (separate, not independent):
validation/runs/AUTH-1-founder-verification-checklist-2026-03-19.md
- Acceptance criteria:
validation/reviews/AUTH-1-independent-reexecution-acceptance-criteria.md
- Verdict template:
validation/reviews/AUTH-1-independent-reexecution-template.md
- Filed review (founder mode):
validation/reviews/auth-authorization-AUTH-1-review-2026-03-19.md
- Evidence packet:
validation/evidence-packets/auth-authorization-AUTH-1-2026-03-19.md
Fast Navigation
- Find a domain/run quickly:
rg -n "AUTH-1|backend|deployment" validation
- Find mode declarations and status labels:
rg -n "independent re-execution|artifact review only|PASS|FAIL|NOT TESTED" validation
- List runs:
ls -la validation/runs
- List reviews:
ls -la validation/reviews
- List evidence packets:
ls -la validation/evidence-packets
- List templates:
ls -la validation/templates
Refusal Conditions
- Refuse to mark
independent re-execution if you only inspected artifacts.
- Refuse to upgrade domain status labels without explicit owner authorization.
- Refuse to assert compliance if version-bound evidence is missing.
- Refuse to file a verdict that lacks operator identity or execution environment.
- Refuse to author both a builder claim and a verdict on the same artifact in the same session.
Filing Conventions
- One file per artifact (run, review, evidence packet).
- Stable IDs in filenames.
- Append-safe, auditable updates over in-place historical rewrites.
- Consistent verdict language across reviews.