Set and raise standards

Use a standardStandard↗A held limit for a repeatable project measurement. when an improvement matters enough that future changes should preserve a measured limit. Your agent handles the measurement and configuration. You decide what is worth holding and whether a later tradeoff justifies changing it.

For example, you can track the amount someone downloads to open your app. Keeping that size in view helps prevent a useful saving from disappearing as agents add features.

The project should already be set up with discerndiscern↗A tool that installs and runs an agent development practice in a project.. Bring the quality you care about; you do not need to know its measuring tool or the files involved.

Use discern-set-the-standard to propose a limit for the app's initial download size. Explain exactly what it would measure, the current value, and how it would handle normal growth. I want to review the proposal before it becomes project policy.

The skillSkill↗A reusable playbook that tells an agent how to handle a particular kind of task. guides your agent through choosing, wiring, and checking the measure. If the concern cannot be judged by a repeatable number, the agent may recommend a checkpoint or another kind of check instead.

Ask the agent to explain the proposal in terms you can assess:

• Meaning: What would an increase or decrease tell us about the app?
• Repeatability: Will the same project state give the same result?
• Cost: Can the project afford to measure it during completion?
• Growth: Will useful new features change the number even when nothing has got worse?

For download size, define which files and units count. For a growing quantity, consider a rate or deliberate headroom. For something the project intends to remove, such as remaining uses of an obsolete implementation, a raw count can be appropriate.

Start with a limit the project currently meets. A hoped-for improvement belongs in a task plan; setting that future value as today's limit would block ordinary work before the improvement exists.

After you agree the proposal, your agent writes the measuring command and adds the standard to discern.toml. It records what the number means so future agents can understand the reason for it.

An illustrative project that currently measures 1,200 kB might use:

[standards.download_size]
direction = "down"
limit = 1200
margin = 100
run = "tools/measure-download-size"

Here, down makes the limit a maximum. up would make it a minimum. The 100 kB margin leaves headroom when a later improvement is pinned; the current limit is still 1,200 kB.

tools/measure-download-size is a project-specific script the agent would provide, not a command shipped by discern. It builds or reads the agreed files and emits the measurement:

DISCERN_METRIC download_size 1200

The producer must complete successfully and supply a valid measurement. A missing number, a failed command, or a value outside the limit needs attention.

If the project already produces this measurement during another check, the agent points the standard at that check with producer = "jobs.<name>" instead of running a second command; the test run that already reports coverage, for example, can supply a coverage standard without running twice. A standard can also declare the files its measurement reads, so an unchanged measurement is reused rather than repeated; a standard that declares nothing is measured again for every version. The configuration reference holds those fields.

Ask the agent to demonstrate that the standard accepts the current app and catches a representative breach. A test in a disposable fixture can show the failure without leaving the project in that state.

The agent measures a named standard with discern_standards, or:

discern standards download_size

You should receive the measured value, held limit, and evidence that the failing case is detected. The agent then runs discern_prepare, commits the intended change, and runs discern_done. Review and land the policy through Finish and land a change.

A breach deserves investigation before a policy decision. Ask:

Explain the measured change and what caused it. Look for reasonable fixes within this task. If the increase is part of the feature we want, show me that tradeoff rather than cutting unrelated useful work.

For example, after a previous improvement lowered the ceiling to 1,000 kB, a new feature might measure 1,040 kB. The agent should explain the extra 40 kB and what it buys. Repair a broken measuring command before reconsidering the size limit.

The agent keeps the held limit while it investigates. Removing the standard, shrinking what gets measured, or raising the limit by hand would change the rule instead of resolving the result.

If a reasonable implementation can fit the existing limit, have the agent make that change. If the extra size is justified, ask for a formal proposal. You can also defer the feature or choose a smaller version.

Your decision should be about the outcome. For example: is the new search useful enough to justify the additional download, and is there a simpler alternative with the same benefit?

Permission to land the feature does not also approve weakening its standard. That separate decision keeps the measurement's cost visible.

Once you agree a proposal is warranted, the agent finishes the implementation and commits its final tree. It then runs:

discern standards propose download_size --reason "The agreed search feature increases the initial download"

The command measures the named standard, creates the proposal's configuration commit, and records its value and reason. The agent follows the result's next action and produces current Proof.

Review the exact old limit, proposed limit, measurement, and reason together. If you approve that proposal, the agent uses its returned token at acceptance:

discern accept --confirmed --approve-standard <token>

The token must match the current proposal. Further edits may require renewed measurement and proposal evidence; the agent follows the reported recovery rather than carrying forward an old approval for a different value.

When a change improves an existing measure, ask to retain the gain:

Pin the download-size improvement, keeping our configured margin. Show me the measured value and the new ceiling, then finish the resulting change through the gateGate↗The configured checks a change must satisfy for ordinary completion..

On a clean committed tree, the agent runs:

discern standards --pin download_size

If the old ceiling is 1,200 kB, the new measurement is 900 kB, and the margin is 100 kB, pinning sets the ceiling to 1,000 kB. It commits that limit change separately. Pinning cannot loosen a limit, and an improvement smaller than the margin may leave nothing to pin.

discern reuses compatible measurement evidence when available. Pinning itself does not establish completion for the new commit: follow the result and renew the full gate evidence before landing.

For a count you intend to reduce to zero, ask the agent to plan a permanent check for the first new instance. Keep the standard until any replacement policy has been explicitly reviewed; deleting a held standard on an ordinary branch fails the gate.

A useful standard has an understandable purpose, a working detector, and a limit the project can meet. Once its policy lands, later work must satisfy it. When an improvement is pinned or a limit proposal is approved, the final completion evidence should describe that exact change.

Standards explains retained gains with a worked example. Fix a red gate helps when the measurement cannot run, and the configuration reference lists every setting.