---
name: setup-extract
description: Extract source-grounded career evidence from papers, employment records, project documents, and notes into structured knowledge-base files without promoting inference to fact.
---

# Source Evidence Extraction

Use this skill when adding new evidence to `knowledge_base/extractions/`. Extraction preserves what a source supports; it does not tailor claims to a vacancy.

## Required inputs

1. Read `config.md` and the anti-fabrication rules in `AGENTS.md`.
2. Read the complete source material.
3. Check `resume_builder/canonical/claims.json` for existing facts and identifiers.
4. Inspect related extraction files so new evidence does not create a duplicate or contradiction.

Generated resumes, cover letters, critiques, and session files under `output/` are never evidence sources.

## Extraction procedure

### 1. Identify the source

Record:

- source filename and type;
- source date, if known;
- whether it is primary evidence, user-authored notes, or a secondary description;
- the person, employer, project, or publication it concerns.

### 2. Separate evidence from inference

For every potentially reusable fact, record:

- the source-supported statement;
- the exact supporting passage or precise location;
- any interpretation separately as `Inference`;
- confidence: `verified`, `user-confirmed`, `needs verification`, or `do not use`.

Never silently convert an inference into a verified claim.

### 3. Capture career facts precisely

When applicable, extract:

- exact employer, formal title, location, and start/end dates;
- ownership scope and collaborators;
- work performed, method, technology, and domain;
- outcome and beneficiary;
- metrics with units, baseline, period, and attribution;
- publication status, authorship position, and venue;
- current versus historical skill use;
- certification versus practical experience.

For large-company work, describe only the user's component, domain, pipeline, service, or contribution. Do not infer ownership of organization-wide platforms or transformations.

### 4. Record claim controls

For each major claim, include where useful:

- allowed verbs;
- verbs or framings that would overstate ownership;
- safe resume wording;
- known contradictions requiring resolution;
- whether a metric is verified, qualitative only, or still missing.

### 5. Write the extraction

Create or update a focused Markdown file in `knowledge_base/extractions/`. Use a clear structure such as:

```markdown
# Subject

## Source
## Verified facts
## Ownership and attribution
## Outcomes and metrics
## Skills and recency
## Safe claim seeds
## Inferences / open questions
## Conflicts with existing KB
```

Claim seeds are factual building blocks, not polished resume bullets. Do not add unsupported impact language for relevance.

## Publication rules

- Never infer `published`, `accepted`, or `under review` from a manuscript file.
- Preserve the user's author position.
- Institutional funding is not a personal award.
- Follow `config.md` provenance flags.

## Completion

Report:

- files created or updated;
- newly verified facts;
- unresolved contradictions or missing metrics;
- suggested next command: use `setup-build-kb` to promote reviewed evidence into the canonical registry, experience files, bundles, and support files.

Do not update canonical claims from an unreviewed extraction.
