Good data is the smallest verifiable unit of model improvement
We do not treat data as content awaiting processing. We treat it as capability evidence composed of a task, reference, verification, run and judgment.
Scale answers how much can be produced. Method explains why the result deserves to enter a model.
The same task can remain text—or become a training signal, diagnostic instrument or release decision. The difference is whether the capability is defined, the task is valid, the evidence closes and review can explain disagreement.
Prove the data is valid before scaling it
Verification changes by domain. These five principles do not.
Capability delta first
Data earns value by identifying, training or validating a specific capability—not through row count alone.
Task validity first
A task must be clear, solvable and discriminative, applying necessary rather than accidental pressure to the target capability.
Operating evidence first
Source spans, reference derivations, tool traces, runtime logs and reviewer rationale support the conclusion together.
Reproducibility first
Environment, dependencies, data versions, verifiers and randomness boundaries must allow critical results to be independently rerun.
Explain disagreement
A quality system does not hide disagreement. It retains divergent judgments, responsibility and the final ruling.
What an acceptable data unit contains
Not every program uses the same schema, but complex work normally covers these six layers.
Task specification
Target capability, input boundary, allowed tools, completion conditions and explicit failure definitions.
Reference and rubric
Expert reference, critical steps, partial credit, edge cases and unacceptable behavior.
Verification mechanism
Source checks, symbolic or numerical validation, hidden tests, environment reruns or specialist review.
Run evidence
Model and input versions, action–observation chain, logs, artifacts and verifier results.
Judgment record
Independent reviews, confidence, disagreement, escalation and final adjudication.
Version state
Draft, calibration, rework, accepted or retired—with evidence for every transition.
A data release is not the endpoint
An effective production system uses model failures to redefine the next task release instead of repeatedly scaling one task pattern.
Define the boundary
Locate the target capability in model errors, operating risk or a gap in the current evaluation.
Construct the task
Qualified authors produce the task, reference, rubric and verification logic together.
Verify independently
Independent solves, reruns, blind review or hidden tests establish task and answer validity.
Stress the model
Expose shortcuts, contamination, ambiguity, judge bias and unstable environments.
Release a version
Accepted, rework and retired states form an auditable benchmark release.
Return to the model
Failure distributions determine the next tasks, training data and evaluation version.
Every task is recalibrated to samples, model stage, runtime, data rights and security requirements. This public method does not replace project-specific acceptance criteria or imply unconfirmed client relationships or certifications.
Build data around your next capability goal
Start with a task goal and a sample. Define the materials, specialists, verification methods and delivery scope together.