Domain

Career

My professional history as linked, cited knowledge, and the resumes and answers built from it.

It started during a job search. I had to rebuild what I had done from memory, decide what mattered for each role, and explain my career to every AI tool again, one conversation at a time. Letting a model fill the gaps was worse than doing it by hand.

Career keeps that history once, connected and checked. It is the domain AlanOS grew from, and the only one with an interface on the internet: its public part answers the Ask AI assistant on this site.

What it holds

Linked knowledge
Projects, skills, technologies, situations, achievements, organisations, education and credentials. Each is a Markdown entry with a stable id and checked links, readable by people and by tools.
The evidence behind it
Certificates are kept as originals, each with one record I have attested. An entry marked as verified must cite such a record, or the validator refuses it.
Three levels of visibility
Every entry is public, personal or confidential, and private by default. Only the public part can reach the internet.

From a job description to a resume

  1. 01

    Understand the role

    A model turns the job description into structured requirements, and a schema checks what it returns.

  2. 02

    Find the evidence

    Search finds the relevant knowledge, and a model judges how relevant each piece is, inside limits set by code.

  3. 03

    Fix the plan

    Code decides the positioning, how much of each role to show, and which evidence each section may use.

  4. 04

    Write within the plan

    A model turns the plan into prose. It cannot add a role, a project, a number or a claim.

  5. 05

    Check every claim

    Each sentence is traced back to the approved evidence. Anything unsupported stops the run.

  6. 06

    Render and archive

    The resume is rendered to HTML, PDF and Word, and the whole run is kept, so I can always see why a claim is there.

The job watch

I write want profiles: the work I want next and the conditions I am looking for. A model reads each job ad against them, using only the ad's own words, and code checks every answer and works out the match. Next to the match, Career shows how much of what the ad asks for my evidence covers. That never ranks an ad away, and the job watch applies for nothing.

The boundaries

Models phrase, code decides
A model may extract, rank and phrase. Schemas, selection, privacy and validation belong to code.
A gap stays a gap
When a job asks for something my evidence does not show, Career reports it as a gap. It never stretches a claim to fit.
Interfaces are adapters
A command line and a local MCP server see everything; a remote MCP server sees only the public part, read-only, behind a token. Every answer says exactly how to cite it.
Search chosen by measurement
Retrieval runs on QMD, picked after comparing it with the previous engine against the same frozen career benchmark.

Search is built on tobi/qmd, a local engine that combines keyword search, vector search and reranking. Career is written in TypeScript with Zod, renders with React and Playwright, and is tested with Vitest, retrieval benchmarks and visual regression tests.

It follows the same constitution as every other domain, and the runtime reaches it through the same kind of interface.

Ask it yourself

Career is a record I no longer rebuild from memory. The tools around it can change, and the evidence and the knowledge stay.