# Metrics And Truth

Resume impact language must be useful without becoming inflated. Numbers are powerful only when they are true, explainable, and defensible.

## Truth Rules

- Do not invent metrics.
- Do not create fake precision from vague evidence.
- Do not upgrade partial contribution into sole ownership.
- Do not present old or adjacent experience as current direct experience.
- Do not imply credentials, tools, platforms, or clients that were not supplied.
- Do not restore a stronger claim that an earlier pass softened, cut, or corrected unless new evidence supports the upgrade.
- Mark missing facts as `[MISSING INFO: ...]`.

## Correction History And Anti-Restoration

A prior correction is evidence. If an earlier tailoring pass softened a verb,
removed a bullet, narrowed a job title, corrected ownership, or replaced a
metric with non-numeric impact language, later audits should preserve that
truth calibration unless the user supplies new supporting evidence.

Check correction history in the lowest-cost available source:

1. The prior resume version kept beside the current draft.
2. Notes on the current file.
3. A feedback log or paired config.
4. The candidate's most recent self-authored version.
5. The candidate's explicit correction in the current conversation.

Do not treat "stronger" as automatically better. Stronger language is only an
improvement when the evidence supports the stronger scope.

## Scope And Truth Window

Some verbs imply ownership of a whole arc:

- identified
- pitched
- secured
- owned
- led
- drove
- launched

Use these only when the supplied evidence supports that scope. If the candidate
joined mid-project, supported a phase, or contributed a narrower artifact, use
accurate partial-scope language instead.

The reverse also matters: do not hedge a claim when full ownership is confirmed.
Make the claim or do not make it, but keep the wording inside the evidence.

## Metric Statuses

Use these statuses internally when evaluating a metric:

- Verified: exact number appears in supplied evidence or the user confirms it.
- Estimated: calculation path is transparent and the user approves the estimate.
- Needs review: evidence hints at the metric, but the number or scope is uncertain.
- Missing: no number is available.
- Blocked: the request asks for invented, inflated, or unsupported numbers.

## Metric Reconstruction

When a user wants stronger impact language:

1. Look for exact numbers in supplied evidence.
2. If exact numbers are absent, look for a transparent calculation path.
3. If calculation is possible, label it as an estimate and ask for approval before final use.
4. If no metric is supported, write non-numeric impact language.
5. If the user asks for a plausible number without evidence, refuse that part and offer a truthful alternative.

## Non-Numeric Impact Language

Use when metrics are missing or sensitive:

- reduced ambiguity
- clarified ownership
- shortened review cycles
- improved handoff quality
- made decision risks visible
- standardized repeatable work
- improved consistency
- increased stakeholder alignment
- reduced manual effort
- created a reusable workflow

## Safe Output Shape

```markdown
## Metric Check
- Status:
- Claim:
- Support:
- Prior correction history:
- Safe resume language:
- Needs verification:
- Do not say:
```

## Examples

Supported:

```text
Supplied evidence says customer response time fell from 48 hours to 24 hours.
```

Safe language:

```text
Reduced customer response time by 50% by standardizing intake, routing, and follow-up workflows.
```

Missing:

```text
Supplied evidence says the process became easier, but no number is available.
```

Safe language:

```text
Reduced process friction by standardizing intake, clarifying ownership, and documenting repeatable next steps.
```
