Post cover image

June 11, 2026

Building a CV pipeline.

Seventy-three percent of enterprise CV adaptation projects exceed their initial compute budgets by a factor of four within the first…

Mohammed Brückner

10 min read

Seventy-three percent of enterprise CV adaptation projects exceed their initial compute budgets by a factor of four within the first quarter of deployment.

OFFICE OF THE FIELD ENGINEER

TECHNICAL IMPLEMENTATION MEMORANDUM 58–7

SUBJECT: The Professional Dossier Transmogrifier — Status and Schematic Review

Golly, the boys in the research division really outdid themselves this time. When the brass handed down the blueprints for the Automated Professional Dossier Transmogrifier, a few of us in the field unit thought they had been hitting the atomic cola a bit too hard. A machine that takes the messy, inconsistent resumes of our American workforce and polishes them into standardized, company-approved formats? Swell idea on paper, but the mechanics of making it happen seemed liable to jam the gears. Having spent the last month deploying the system at the client site, I can report that the promise of the Atomic Age remains intact. American Ingenuity has delivered a marvel, provided you respect the operational boundaries of the apparatus.

The genius of this system lies in its foundational restraint. The architects understood that not every document requires the intervention of an Electronic Brain. Sometimes, a file merely needs to migrate from an old template to a new one. The system provides a deterministic extraction layer for exactly this scenario. We take the source CV, process it locally, and prepare the material for rendering without ever pinging a remote model. This architectural decision removes non-determinism, reduces operational cost, and provides a stable base path ensuring the application remains useful even without external model calls.

Deterministic Extraction and Content Modeling

The deterministic pipeline relies on local file parsing and strict data marshaling. When a document-style input enters the system, a local extraction engine reads the source CV. The extraction logic must handle inconsistent formatting, variable section headers, and non-standard date representations. Parsing a CV requires navigating unstructured text, often requiring regular expressions to isolate key-value pairs from varied typographical layouts.

None

The extracted data is normalized into a structured payload, explicitly defined as a large JSON object. This JSON schema represents the internal content model. A typical schema implementation separates the candidate's information into distinct semantic units.

{
  "candidate": {
    "name": "string",
    "contact_info": {
      "email": "string",
      "phone": "string"
    }
  },
  "experience": [
    {
      "company": "string",
      "role": "string",
      "dates": {
        "start": "YYYY-MM-DD",
        "end": "YYYY-MM-DD"
      },
      "responsibilities": [
        "string"
      ]
    }
  ],
  "skills": [
    "string"
  ]
}

This data marshaling step serves four critical functions: preserving section boundaries, preserving field-level meaning, making downstream processing predictable, and protecting the document from random formatting drift. The rendering harness then maps these normalized fields into the target CV layout using a templating engine such as Jinja2. The renderer enforces the current company layout, maintaining consistency of headings and content placement, and produces a clean document artifact without any AI intervention. The baseline structure remains the reference point for all later variants. The system implements an internal content model that supports basic re-rendering, translation of sections, guided rewriting, and customer-specific adaptation. Typical responsibilities of this layer include preserving the original semantic units, separating content from presentation, supporting reversible inspection before rendering, and feeding the same content into deterministic and AI branches.

Reformatting is swell for the filing cabinet, but the modern enterprise demands semantic augmentation. Sometimes a dossier must speak the language of a foreign subsidiary, or perhaps the tone needs adjusting to charm a specific client. This is where the system enables the AI path. We normalize the CV into that structured payload, and only then do we invite the model to the party. The application does not treat the CV solely as free-form prose; the structured layer decouples document ingestion from semantic transformation and final rendering. We have three augmentation modes: translating into another language, tailoring to a target customer, and applying a guided semantic rewrite.

Structured Payloads and Model Invocation

Passing unstructured text to a Large Language Model (LLM) for translation or adaptation yields highly variable results. The CV Transmogrifier mitigates this by sending the structured JSON payload to the model endpoint, utilizing APIs such as the OpenAI Chat Completions API. The API call explicitly structures the prompt to constrain the model's output format. We use system messages to enforce JSON output and specific user prompts to trigger the desired transformation.

import openai
import json

def translate_cv_section(cv_payload, target_language):
    response = openai.chat.completions.create(
        model="gpt-4-turbo",
        response_format={ "type": "json_object" },
        messages=[
            {"role": "system", "content": f"Translate the following JSON values into {target_language}. Maintain all JSON keys in English. Output only valid JSON."},
            {"role": "user", "content": json.dumps(cv_payload)}
        ]
    )
    return json.loads(response.choices[0].message.content)

This structured approach preserves the original information layout and reduces formatting corruption, allowing the system to reconstruct the document accurately after translation. The source material indicates that personal OpenAI API keys were used in this flow, meaning the runtime is capable of external model invocation for at least some augmentation scenarios.

The customer-fit mode introduces an external research step before rewriting. The application looks up the target company on the internet, considers the existing CV, and adjusts the content to better fit the intended customer context. This involves querying an external search API or internal vector database to retrieve context about the target company. This external context is injected into the model's prompt, instructing the AI to adjust the CV content to align with the target customer's known technical stack or corporate culture. Because the output is inherently non-deterministic and crosses from structural transformation into persuasive adaptation, this path carries the highest risk of factual drift. The exact retrieval mechanism is not specified, but architecturally it is explicit that external company context is introduced before rewriting, and the output must be reviewed.

The guided rewrite mode captures the broader class of content changes enabled by the same harness once the document has been normalized. The source material suggests several possibilities: expanding content, adjusting content, and generating alternate variants for different contexts. The key point is that once the content is structured and the prompts are constrained, the same pipeline can support multiple transformations without redesigning the application each time.

None

The model output does not become the final deliverable directly. It must be brought back into the application harness and aligned with the internal content model. Responsibilities at this stage include mapping transformed output back into expected sections, preserving required structure for final rendering, and constraining content drift before document generation. The transformed content becomes input to a second, target-format document construction step.

This content merge stage combines the stable target CV structure with the newly transformed semantic content. This is not merely a visual formatting step; it is the point where semantic changes become a presentable document. In a robust implementation, this layer would need to preserve required sections, prevent accidental loss of original facts, maintain rendering compatibility, and support repeated output generation for different variants. Even though the exact code path is not disclosed, the application behavior clearly implies a merge between transformed semantics and a target document skeleton.

Left to its own devices, an Electronic Brain might decide that an engineer was an astronaut, or that a salesman single-handedly won the Cold War. We cannot have machines inventing facts on company time. The system implements an AI control harness of remarkable rigor. The application stores its system description in Markdown files. Every package and component is documented. This documentation is not passive reading for the boys in the office; it is reused as control input for the AI. The docs layer serves as a human-readable system map, grounding context for model prompts, an architectural constraint surface, and a consistency mechanism across features.

Prompt Engineering and Documentation Grounding

The AI control harness mitigates hallucination and scope creep through strict prompt rules and contextual grounding. The Markdown documentation is injected directly into the model's context window during invocation. This grounds the model's behavior in the actual state of the application. The system enforces two primary prompt directives: the no-invention rule and the surgical-change rule. The no-invention rule explicitly instructs the model via system prompts to avoid generating unsupported claims or fabricating code behaviors. The surgical-change rule constrains the model to make only targeted modifications, preventing unrelated rewrites that could introduce regressions.

SYSTEM PROMPT DIRECTIVE:
1. You are operating on a structured CV payload.
2. DO NOT invent facts, skills, or experiences not present in the input JSON.
3. Make surgical changes only to the specific fields requested.
4. Output must conform strictly to the input JSON schema.

Natural-language pre-planning is another core control mechanism. Features are described conceptually before implementation. This conceptual description drives task creation and compatibility checks against the existing application. Because the documentation is available in the agent's context, a new feature request can be evaluated against existing functionality using semantic similarity search over the Markdown embeddings. This design-time reasoning step asks whether the requested feature conflicts with existing behavior given the current documented system. Package-level intent documentation further constrains the AI; since each package is documented separately, the AI can be guided by local component intent, improving modular consistency and explainability during code review.

The validation gate is not optional process overhead; it is a core safety mechanism. Deterministic processing can be trusted strongly because no model invents content and the task is primarily extract-and-reformat. AI-generated adjustments require human review because models may hallucinate unsupported claims, and customer-specific adaptation can drift into content that is plausible but factually ungrounded. The source material is explicit that this cannot be validated in a fully deterministic way and that a human should review whether the result actually makes sense. Therefore the harness intentionally distinguishes between machine-trustable structural conversion and machine-assisted but human-approved semantic transformation.

Perhaps the most startling feature of the Transmogrifier is how it evolves. The development process begins with intent, not code. Features are described in natural language. We use a stronger model for planning and design reasoning, then generate persistent implementation artifacts. The planning conversation produces durable artifacts — implementation plans or feature definitions that convert conversation into operational inputs. The work is decomposed into parallelizable tasks, and coding agents execute the work against the repository. The improved application feeds the next runtime cycle, closing the loop between idea, plan, generated implementation, review, validated package, and operational usage. The result is an evolving application whose development speed improves as the harness matures.

Agentic Development and CI/CD Integration

The development harness employs a tiered model strategy. High-capability models handle planning and architectural reasoning where the cost of failure is high. Cheaper, faster models handle implementation-heavy tasks where throughput matters more than deep reasoning. The planning phase uses a stronger model because planning needs higher reasoning quality than routine code generation. A mini-class model and a Haiku-class model are both mentioned as cost-efficient options for implementation-heavy work, while stronger engines are preferred for planning.

The workflow executes as follows: First, a feature is defined in a natural language prompt file. Second, a planning agent — a strong model — reads the specification and the existing repository context, generating a detailed implementation plan. Third, the plan is parsed into independent, parallelizable coding tasks. Fourth, autonomous coding agents check out branches, write code, and commit changes. GitHub serves as the execution surface. Fifth, generated changes land as pull requests, ensuring versioned traceability and rollback safety. This gives the system visible change units and review boundaries.

Automated review acts as a critical guardrail. Pull requests are reviewed by an independent AI system, such as Codex, and at least one additional automated check path. This multi-stage quality pattern provides an extra perspective beyond the original generating agent, improving alignment with documentation and surfacing issues before merge.

name: AI PR Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4
      - name: Run Linting and Type Checking
        run: |
          pip install ruff mypy
          ruff check .
          mypy .
      - name: Run AI Reviewer
        uses: ai-codex/review-action@v1
        with:
          api_key: ${{ secrets.CODEX_API_KEY }}

Test coverage serves as the ultimate execution guardrail. Extremely high test coverage, targeting 90 percent or higher, is a core control mechanism. Generated code must be checked continuously; automated reviewers use test outcomes as quality evidence. Confidence in merged code depends on executable validation, not only on plausible-looking source text. Once validated, changes merge into a modular Python package. The modular packaging supports reuse, importability, extension over time, and a move away from one-off scripts into a reusable tool. The application exposes a Command Line Interface (CLI) for direct practical use, supporting easier local execution, simpler demonstrations, and repeatable runs without editing the source code.

The backbone of this entire operation, both for the Electronic Brain and the human operators, is the documentation. The project demands that every package and application component is documented in Markdown. This documentation must remain human-readable so the system stays inspectable. The same documentation is injected into AI context windows, used to pre-check new ideas against current behavior, and maintained as examples and templates for rapid re-entry into the project. Supporting fast local understanding requires running examples and inspecting outputs. A project that has not been touched for some time can still be resumed quickly looking at examples, running them, and observing the result. The harness supports re-entry speed, not only original development speed. Documentation influences the AI control layer, the development layer, and the rendering path, because the application structure and expected behaviors remain understandable and reproducible.

Running an Electronic Brain costs a significant amount of computational allocation. The system does not treat every model invocation equally. It distinguishes between reasoning-heavy planning work, implementation-heavy tasks, and review and verification. This enables a practical cost and performance balance. We keep human verification for outputs that cannot be deterministically validated, because even with strong tooling, some output classes remain non-deterministic. The operational model is automated acceleration with explicit review boundaries.

Model Routing and Human-in-the-Loop Validation

Cost optimization in the Transmogrifier relies on intelligent model routing. A dispatcher function analyzes the incoming task and routes it to the appropriate model tier based on complexity and required reasoning depth.

def route_model(task_type, payload):
    if task_type == "architectural_planning":
        return "gpt-4-turbo"
    elif task_type == "code_implementation":
        return "gpt-3.5-turbo"
    elif task_type == "code_review":
        return "gpt-4-turbo"
    elif task_type == "cv_translation":
        return "gpt-4-turbo"
    elif task_type == "cv_tailoring":
        return "gpt-4-turbo"
    else:
        return "gpt-3.5-turbo"

Human verification remains non-negotiable for specific output classes. The validation gate distinguishes between machine-trustable structural conversion and machine-assisted but human-approved semantic transformation. Deterministic processing can be trusted strongly because no model invents content; the task is primarily extract-and-reformat. AI-generated adjustments require human review because models may hallucinate unsupported claims. Customer-specific adaptation can drift into content that is plausible but factually ungrounded. The system routes AI-transformed content to a human review queue, often implemented as a Slack notification or a dashboard entry, requiring explicit approval before the final document is released. The human acts as the final gatekeeper, ensuring the machine's acceleration does not compromise the factual integrity of the professional dossier.

Final Field Assessment

Having put the Transmogrifier through its paces, I can assure the home office that the future of personnel documentation is bright. The machine does the heavy lifting, parsing the chaotic scrawl of the American worker into neat, orderly JSON payloads, and rendering them into standardized templates with the reliability of a Chevrolet assembly line. When the Electronic Brain is needed, it operates under the strict supervision of the Markdown documentation and the surgical-change rules, ensuring it does not run off the rails. The self-building development harness is a particular marvel, letting our engineers describe features in plain English while the agents write the code. We must keep our hands on the validation lever, especially when the machine tries to tailor a CV for a new client, but that is just good American common sense. The Atomic Age of enterprise software is here, and it is swell.

More actionable advice over at https://mohammed-brueckner.com/publications — and discover the playbook for surviving the compression in the agentic era with my new book at https://platformeconomies.com (coming Sept 1, 2026)