01
Observed fact
Directly inspectable in the current repository, system, diff, or recorded result.
True only for the observed state and time.
METHODOLOGY
Trust comes from visible boundaries.
Baseline does not ask you to trust a popularity signal or a broad promise. It makes the governing input, risk, evidence, limitations, and authority behind a software change easier to inspect.
Evidence-driven engineering means making the basis of a claim explicit—and keeping the claim no broader than that basis.
Baseline combines established software-engineering practices with explicit product decisions about proportionality, portability, safety, and human authority. It is not a claim that every workflow is scientifically proven or that declarative instructions can enforce an agent's behavior.
The standard is narrower and more useful: state what was observed, how it was checked, what remains uncertain, and what would make the conclusion change.
EVIDENCE LANGUAGE
Different claims require different labels.
These categories prevent repository state, specifications, tests, empirical observations, and judgment from being presented as if they carried the same confidence.
02
Governing specification
The request, contract, accepted decision, or policy that defines expected behavior.
Defines intent; it does not prove implementation.
03
Executable check
A reproducible test, build, validator, or inspection that distinguishes an expected result.
Supports the checked boundary, not universal correctness.
04
Empirical validation
Behavior observed with a named client, version, fixture, model, or environment.
Does not transfer automatically to other configurations.
05
Heuristic
A practical routing signal or engineering rule that guides judgment under uncertainty.
Useful guidance, not an enforced guarantee.
06
Product decision
An intentional Baseline choice about scope, proportionality, portability, or authority.
A design commitment, not an external fact.
07
Inference
A conclusion that connects evidence to a decision or risk assessment.
Must stay labeled and revisable when evidence changes.
PROPORTIONALITY
Risk selects the depth.
Baseline classifies the highest applicable risk from blast radius, crossed boundaries, reversibility, ambiguity, persistence, public compatibility, validation difficulty, rollout, and rollback. Line count is not a risk model.
Contained
Simple recovery, narrow behavior, direct validation.
Crossing a boundary
More than one surface, public behavior, or meaningful integration.
Material exposure
Broad blast radius, difficult validation, persistence, or rollout risk.
Critical consequence
Sensitive systems, hard reversal, broad authority, or severe failure cost.
FAIL-FIRST TO VERIFICATION
A green check matters only after the right red signal.
The smallest useful check must first fail for the expected behavioral reason. The implementation then changes the behavior—not the assertion—and review reconnects the result to the full governing input and diff.
- 01
Define the boundary
Translate the governing input into observable expected behavior.
- 02
See the right failure
Confirm the check distinguishes the missing behavior from infrastructure noise.
- 03
Change the minimum
Implement the smallest coherent behavior without weakening the evidence.
- 04
Review the whole story
Reconcile request, behavior, tests, diff, risks, fresh results, and limitations.
SAFETY AND ISOLATION
Safety is more than a sandbox.
Source state, execution, machine and kernel, mutable services, credentials, approval, and verification are separate boundaries. Strengthening one does not silently strengthen the others.
01
Source state — branch, worktree, and concurrent changes
02
Execution — processes, dependencies, generated commands, and network
03
Machine — filesystem mounts, user, kernel, device, and privileges
04
Services — databases, queues, buckets, emulators, and shared state
05
Authority — credentials, approvals, external mutations, and destructive actions
06
Verification — preserved diff, logs, results, limitations, and integrated review
CLAIM BOUNDARIES
What Baseline does not claim.
Skill discovery does not prove that a model selected or followed the workflow correctly.
A passing test does not establish correctness outside the behavior and environment it checked.
Declarative guidance does not enforce permissions, isolation, review quality, or production policy.
Client compatibility does not transfer behavioral evidence across versions, models, or configurations.
Proportionality does not mean skipping necessary rigor; the highest applicable risk wins.
Human authority cannot be inferred from an earlier engineering step or a successful local result.
INSPECT THE EVIDENCE
The repository is the product.
Baseline's public contract, vocabulary, workflow composition, deterministic tests, and evaluation limits remain reviewable in source.
APPLY THE METHOD
Bring the minimum discipline into your repository.
Install the static skills, then let $setup-baseline create or safely reconcile the project-owned engineering contract.