What Constitutes the Primary User‑Authored Data in Career‑Ops

The primary user‑authored data in career‑ops comprises immutable personal artifacts—including your résumé, identity configuration, application tracker, and interview story bank—that reside exclusively in the User Layer and are never modified by automated system updates.

Career‑ops enforces a strict separation between user files (which you own) and system files (updated automatically). The primary user‑authored data lives in the User Layer, comprising markdown files, YAML configurations, and TSV logs that serve as the single source of truth for every CV generation, job evaluation, and outreach workflow in the repository.

The User Layer Architecture

According to the repository’s Data Contract documented in DATA_CONTRACT.md, the User Layer contains the only files that you—or the agent acting on your explicit instruction—may add, edit, or delete. These files are never touched by automatic updates, ensuring your personal data remains sovereign. Every script, mode, or template in the system reads from these locations to produce scores, CVs, cover letters, and analytics.

Core Identity and Résumé Configuration

The foundation of your career‑ops instance rests on canonical identity files that define who you are and how you present professionally:

• cv.md — Your résumé in Markdown format serves as the canonical source for work history, achievements, and skills. All CV‑related modes reference this file for generation and validation.

• config/profile.yml — Stores personal identity and job‑targeting parameters including name, email, location, target roles, salary range, and spend tier.

• config/cv-facts.json — An allow‑list of factual statements and forbidden phrases used by the validation system to enforce accuracy in generated documents.

• modes/_profile.md — Contains your archetypes, narrative frameworks, and negotiation scripts. This “profile” shapes how scoring modes interpret opportunities.

• modes/_brief.md — A compact profile brief (approximately 1.5–2K tokens) optimized for first‑pass triage operations.

• modes/_custom.md — Houses your custom workflows, house rules, and output preferences. This file is procedural and preserved across updates.

• voice-dna.md (optional) — Defines voice guardrails including banned words, tone constraints, and style rules applied to all generated text.

• article-digest.md — Stores proof‑points and highlighted portfolio items that may be quoted in cover letters or interview preparation.

Application Tracking and Pipeline Management

The data layer maintains the operational state of your job search through append‑only logs and canonical tracker files:

• data/applications.md — The single source of truth for every job you’re pursuing, recording status transitions and employer interactions.

• data/pipeline.md — Your inbox of URLs awaiting evaluation by the scanner.

• data/status-log.tsv — An append‑only ledger of every status transition, consumed by funnel-velocity.mjs for analytics.

• data/scan-history.tsv — Log of every portal scan performed.

• data/scan-runs.tsv — Counters for each scan run, referenced by stats.mjs.

• data/follow-ups.md — History of follow‑up communications with contacted companies.

• data/active-interviews.md — Current interview pipelines including friction notes and scheduling details.

• **data/offers/** (PII‑protected) — Received offer documents and related preparation drafts.

• **data/outcomes/** — Outcome logs and archived artifacts for each concluded application.

Interview Preparation Assets

Your narrative preparation and company‑specific research live in the interview preparation directory:

• interview-prep/story-bank.md — Accumulated STAR+R stories forming your personal narrative bank for behavioral interviews.

• interview-prep/{company}-{role}.md — Company‑specific interview preparation reports generated by the interview-prep mode.

Calibration and Constraints

Fine‑grained control over evaluation and generation quality resides in specialized configuration files:

• config/benchmarks.yml — Optional overrides for market‑calibration benchmarks used by funnel-velocity.mjs.

• config/local-paths.txt — Lists extra repository‑relative paths that belong to you, such as private scripts or supplementary data.

• data/assessments.tsv — Skills‑assessment records including dates, platforms, scores, and notes.

• data/salary-observations.tsv — Your compensation observations across desired, advertised, and actual offers.

System Interface and Contact Management

Operational interfaces and relationship data complete the primary dataset:

• data/agent-inbox.md — Append‑only request queue for the agent (e.g., “run a scan every 3 days”).

• data/reply-candidates.json — Normalized employer‑reply candidates for the reply-watch mode.

• data/pdf-index.tsv — Mapping of generated PDFs to their source reports, used by the dashboard and email mode.

• data/contacts.tsv — Your personal phone‑book of recruiters, hiring managers, and peers.

• data/Connections.csv (optional) — Raw LinkedIn export consumed by linkedin-join.mjs.

Source Documents and Writing Samples

Raw input materials and style references that you feed into the system:

• **documents/** (optional, git‑ignored) — Source documents for the intake mode including master CVs, LinkedIn exports, and diplomas.

• **writing-samples/** (optional) — Personal writing samples used for style calibration and voice matching.

Generated Reports and Output Artifacts

While derived from primary data, these user‑managed outputs remain strictly under your control:

• **reports/** — Evaluation reports you generate, each referencing the primary data files above.

• **output/** — Generated PDFs, HTML, and other artifacts derived from your canonical sources.

• **jds/** — Saved job descriptions preserved for later reference.

Working with Primary Data

All interactions with the primary user‑authored data follow explicit editing patterns. The system never modifies these files during updates.

Edit your canonical résumé directly:

nvim cv.md

Update your targeting parameters:

nvim config/profile.yml

Add a new STAR story to your narrative bank:

nvim interview-prep/story-bank.md

Record a new application status via the CLI tool set-status.mjs:

node set-status.mjs 042 Applied --note "Submitted via LinkedIn"

Summary

• User Layer files defined in DATA_CONTRACT.md constitute the primary user‑authored data and are never auto‑updated.
• Core identity lives in cv.md, config/profile.yml, and modes/_profile.md.
• Operational state resides in data/applications.md, data/status-log.tsv, and data/pipeline.md.
• Interview assets include interview-prep/story-bank.md and company‑specific prep files.
• All other system scripts read from these locations to generate evaluations, CVs, and outreach materials.

Frequently Asked Questions

What distinguishes user‑authored data from system files in career‑ops?

User‑authored data resides in the User Layer and comprises only the files you explicitly create or modify, such as cv.md and data/applications.md. System files include automation scripts, mode implementations, and templates that the repository updates automatically; these never modify User Layer contents.

Can I manually edit files in the reports/ or output/ directories?

Yes. While reports/ and output/ contain derived artifacts generated from your primary data, they remain part of the User Layer. You retain full editorial control over these files, and the system will not overwrite them during routine updates.

How does career‑ops prevent system updates from modifying my personal data?

The repository’s Data Contract explicitly designates User Layer files as excluded from automatic updates. System scripts and modes possess read‑only access to these paths; write operations require explicit user invocation or agent instructions directed at specific files.

What happens if I modify config/profile.yml or cv.md?

Changes to config/profile.yml immediately affect targeting parameters for scoring modes and compensation calculations. Updates to cv.md propagate to all CV‑generation workflows, cover letter templates, and validation checks that reference your canonical résumé.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}