AxelynForge.

The job of the system

Most resume generators begin by asking a model to rewrite a document. Forge begins one step earlier: what can this candidate actually support?

The system creates a structured, reusable record of the candidate, reads one job opportunity, finds the evidence that matters, identifies the gaps and only then proposes new wording. It produces a tailored resume and cover letter while preserving an existing Microsoft Word design.

Forge does not claim to predict whether a recruiter will interview or hire someone. Its measurements describe evidence and terminology coverage inside the application. Hiring decisions depend on people, competition and circumstances the system cannot observe.

The operating contract

Forge divides responsibility between four sources of authority.

Authority	Controls
Candidate evidence	Facts, experience, projects, skills and achievements that may be claimed
Canonical JSON	Document structure, stable identities and protected factual fields
Word templates	Typography, tables, spacing, content slots and page layout
AI	Context selection and proposed wording inside explicitly editable fields

This separation is the central design decision. The model is useful where interpretation and writing are needed. Deterministic local code controls facts, permissions, validation, rendering and publication.

1. Know the candidate once

Forge stores the master resume as canonical JSON rather than treating a Word file as an unstructured source. The profile contains identity, contact details, locale, a resume variant and seven semantic sections:

1. Summary
2. Professional experience
3. Selected projects
4. Engineering practices
5. Education
6. Technical skills
7. Languages

Every meaningful entity receives a stable ID such as summary-1, axelyn-highlight-1, project-aria or skills-programming. Those IDs survive reordering and connect evidence, rewrite operations, Word bindings and audits without depending on an item’s position in an array.

Supporting Markdown and JSON files add verified detail that may not fit in the compact master resume. Forge divides that material into deterministic evidence chunks and stores the current index in SQLite. Each chunk retains its source, heading hierarchy, order and content hash.

The source documents remain editable by the candidate. The database is an index, not a second truth.

2. Read one exact opportunity

A tailoring run accepts exactly one job source:

• Pasted job-description text
• A UTF-8 text file
• A public HTTP or HTTPS job-posting URL

URL retrieval is deliberately narrow. Forge rejects credentials, local hosts, direct private IP addresses, invalid ports and unsupported schemes. Retrieval is restricted to the supplied hostname and must find the exact posting. If the posting is unavailable, the run fails instead of quietly substituting a similar role.

The normalized description and retrieved source URLs are retained in a job-source audit file. The job description is useful context, but it is never treated as a trusted instruction to the application.

3. Select only relevant evidence

Sending an entire career archive to every request increases cost and makes irrelevant material easier to surface. Forge instead gives the context selector the job description and a catalog of available evidence chunks.

The selector returns a strict structured result containing:

• Company and job title
• Central role signals
• Eight to 24 employer keywords
• Material evidence gaps
• A ranked list of evidence chunk IDs

Forge accepts no more than 12 selected chunks. Empty, duplicate, excessive or unknown IDs are rejected. Accepted IDs are resolved locally from the context store, so the main tailoring request sees only verified evidence selected from a known catalog.

4. Measure support before rewriting

Forge classifies employer terminology as required, preferred or responsibility-level, then compares it with the canonical resume and selected evidence using local deterministic rules.

Every concept receives one of four results:

Classification	Meaning
supported-exact	The terminology appears directly in verified candidate material
supported-alias	A controlled equivalent is present, such as a recognised technology or role alias
supported-context	Selected evidence supports the concept even when the compact resume does not state it
unsupported	Forge cannot find candidate evidence for the requirement

Supported concepts become guidance for what the tailored resume should surface. Unsupported requirements remain explicit gaps.

This produces an evidence coverage report, not a hiring probability. A useful result might say that essential requirements have strong coverage while domain experience is unsupported. It should never claim that a candidate has a 78% chance of receiving an interview.

5. Let AI propose operations, not documents

The model never receives permission to regenerate the complete document or manipulate Word markup. It returns typed semantic operations against stable IDs:

{
  "operation": "rewrite",
  "target": "summary-1",
  "field": null,
  "value": "Evidence-backed replacement text"
}

Collection fields declare the field being changed:

{
  "operation": "rewrite",
  "target": "skills-programming",
  "field": "items",
  "value": ["Python", "TypeScript", "SQL"]
}

The AI-editable catalog contains only the profile headline, entities with editable text, skill items and technology lists. Legal identity, contact information, employers, existing job titles, dates, education, entity IDs and entity types stay outside that catalog.

Forge rejects malformed JSON, unknown targets, protected targets, duplicate operations, incorrect value types, empty job titles and rewrite plans that contain only no-op changes. It applies accepted operations to a deep copy and validates the entire profile again before any document is rendered.

6. Preserve the Word design

The Word template remains the authority for presentation. It contains Structured Document Tags that correspond to semantic bindings.

Canonical entity: axelyn-highlight-1
    → field: text
    → binding: experience.axelyn.highlight.1
    → Word content control with the same tag
    → visible text in the rendered document

Forge opens the DOCX package, finds tagged controls across its Word XML parts and replaces only the text owned by those controls. The surrounding paragraphs, runs, tables, numbering, styles and layout remain in place.

The binding layer can resolve absolute document paths or stable IDs, join arrays, combine sources, select semantic objects, remove prefixes and split content into fixed slots. Strict rendering fails when a template tag has no binding, and the source template cannot be overwritten in place.

This is how Forge can improve content without asking a language model to imitate or reconstruct a carefully designed resume.

7. Generate a separately evidenced letter

The cover letter is a second structured generation request based on the validated tailored resume and the same selected evidence. It produces nine complete paragraph roles covering the opening, experience, company fit, collaboration, motivation, value and closing.

Every paragraph carries one or more evidence IDs. Candidate-focused paragraphs must cite candidate entities or selected context chunks. Job-description text alone cannot support a claim about the candidate.

Names, email, location, application date, recipient, company, job title, subject, salutation and signature are assembled locally. The output receives application-specific document metadata so details from an older template cannot remain hidden inside the new file.

8. Publish a complete application package

A successful run can produce:

Resume_[Job_Title].operations.json
Resume_[Job_Title].context-selection.json
Resume_[Job_Title].keyword-alignment.json
Resume_[Job_Title].json
Resume_[Job_Title].docx
Resume_[Job_Title].pdf

Cover_Letter_[Company]_[Job_Title].json
Cover_Letter_[Company]_[Job_Title].docx
Cover_Letter_[Company]_[Job_Title].pdf

URL-based runs also retain a job-source.json audit record.

Forge builds required artifacts inside a temporary staging directory. It publishes them through atomic file replacement only after the complete package succeeds. Failed schema validation, binding, rendering or PDF conversion cannot leave a half-completed application in the final output directory.

PDF conversion runs through headless LibreOffice with an isolated temporary profile. Forge checks that the output exists, is non-empty, begins with a PDF header and contains an end-of-file marker. Because Word and LibreOffice use different layout engines, the DOCX remains authoritative and template changes still require visual inspection.

9. Keep the operation observable

Each model request creates a usage-ledger row before it begins. A workflow may contain four AI stages: URL retrieval, evidence selection, main tailoring and cover-letter generation. Keyword alignment remains local and does not require another model request.

Completed records can include the requested and actual model, response status, service tier, duration, token categories, web-search actions and a versioned public-price estimate. Failed and interrupted requests remain visible for diagnosis.

Prompt text, job-description text, resume content and API keys are excluded from the usage tables.

10. Offer two controlled interfaces

The local command-line interface supports inspection, schema validation, operation application, rendering, PDF conversion, context indexing, usage reporting and the full tailoring workflow.

forge tailor \
  --jd /path/to/job-description.txt \
  --context context/ \
  --template templates/resume.docx \
  --data data/profile.json \
  --bindings bindings/resume.json \
  --output-dir output

A private Discord bot provides pasted-text, file and URL tailoring commands. It uses default-deny authorization, ephemeral responses, exact-one-source validation and one active tailoring operation at a time. Generated DOCX and PDF files return directly to the authorised user with cost, coverage, changed-section and gap summaries.

Multi-profile mode isolates each person’s resume data, context, databases and output directory. Shared templates and schemas are allowed only where compatible. Forge refuses to start when separate profiles point to the same private storage.

11. Deploy without opening an application port

Forge runs in a Python 3.12 Slim container with LibreOffice Writer and metric-compatible fonts. The service runs as an unprivileged user with a read-only container filesystem, dropped Linux capabilities, no-new-privileges, CPU, memory and process limits, rotating logs and a persistent private state volume.

The Discord bot initiates an outbound Gateway connection. It does not need a public application port, domain, reverse proxy or inbound TLS endpoint.

The deployment workflow runs the regression suite before production release. The VPS deploy process accepts an exact 40-character commit, verifies that it is the current production-branch head and creates an immutable release directory. It replaces the service, waits for a successful Discord Gateway connection and moves the current release link only after verification. If the replacement does not become healthy, the script restores the previous release.

This makes deployment part of the integrity model. A valid application package is not enough if the running service cannot be tied to a tested commit or returned to its last known working release.

12. Draw the security boundary around the model

The most important controls are structural:

• API keys enter through environment configuration rather than command arguments.
• Model responses must match strict JSON schemas.
• Job descriptions and retrieved pages are untrusted data.
• Candidate facts must come from the canonical profile or verified context.
• Unsupported requirements remain visible gaps.
• AI operations are checked against an explicit editable-target catalog.
• Stable IDs must be globally unique.
• Canonical data is validated before and after modification.
• Missing Word bindings fail by default.
• Private state is separated from public application files.
• OpenAI requests use store=False.
• Final packages are published atomically.

These controls do not make generative output infallible. They make authority explicit, reduce the model’s ability to change protected information and create inspection points around every consequential transformation.

13. Reuse the pattern

The public value of this Blueprint is the architecture, not a set of magic prompts. The same pattern can support other document workflows:

1. Establish verified source material.
2. Give important entities stable identities.
3. Select relevant evidence before generation.
4. Separate supported concepts from unsupported requests.
5. Limit the model to typed operations over editable targets.
6. Validate the complete result locally.
7. Bind content into a presentation template.
8. Publish outputs and audits as one transaction.

A company can adapt this approach to proposals, compliance packs, reports, client onboarding or other document-heavy work. The schemas, evidence rules and review thresholds should change with the consequences of that workflow.

Technical responsibility map

Forge keeps orchestration, model access, deterministic checks and document rendering in separate modules.

Area	Responsibility
Tailoring orchestration	Coordinates the complete job-description-to-artifact workflow
Context store	Persists deterministic evidence chunks and source metadata in SQLite
Context selection	Requests and validates the ranked evidence subset
Keyword alignment	Compares employer terminology with verified evidence locally
Model provider	Requests and validates typed semantic rewrite plans
Operations	Applies accepted rewrites to a deep copy of canonical JSON
Validation	Enforces JSON Schema and globally unique stable IDs
Bindings	Resolves semantic fields into flat Word template values
DOCX renderer	Replaces tagged text while preserving surrounding layout XML
Cover-letter pipeline	Generates and validates paragraph-level evidence references
PDF converter	Runs isolated LibreOffice conversion and verifies the result
Usage store	Records request status, tokens, duration and estimated cost
Discord interface	Authorises users, routes profiles and returns private artifacts

What remains constrained

Forge works inside fixed template slots rather than inventing arbitrary layouts. It depends on the OpenAI API for full tailoring and on LibreOffice for PDF conversion. DOCX pagination can vary between layout engines. Invalid model output produces a visible failure instead of an unvalidated fallback. Private Discord work is serialized, and cost records remain estimates rather than invoices.

Those limits are part of the system description. A useful Blueprint states where the system stops as clearly as it states what the system can do.

What makes this different from asking AI

A direct AI conversation can suggest stronger wording. Forge provides a repeatable evidence chain from source material to final document. It can show which evidence was selected, which employer terms were supported, which fields changed, which claims remained unsupported and whether the complete output passed its local contracts.

The model contributes language. The system contributes memory, permissions, validation, document fidelity, auditability and a dependable failure path.