The same career, cut two ways.

ResumeData
  → toTypstDoc()        // the ONLY place data is shaped
  → TypstResumeDoc      // plain JSON, every field a string
  → sys.inputs.resume   // main.typ
  → templates/ledger.typ  render(data)
  → typst-ts-web-compiler (~27 MB wasm)
  → compileSvg() preview | compilePdf() download

Templates are pure styling: no filtering, no date logic, and they never receive markup. Because every field arrives as a plain string, user text containing # * _ $ [ ] \ needs no escaping — it is printed literally.

The engine initialises once, lazily, when the preview first mounts; the vendored Inter faces are preloaded and remote font assets disabled, so output is byte-stable across machines. The wasm is single-threaded, so compiles are serialised through one promise chain, and the last good SVG stays on screen at 60% opacity while a new one renders.

If the engine fails to load, the app says so in its own panel — and states explicitly that nothing in your résumé was filtered or rejected.

An item covers a requirement when it carries the exact canonical tag key, a key the requirement's satisfiedBy list accepts, a key the built-in hierarchy accepts (bachelor's degree ← any bachelor of …), or is cited by item id in evidence.

The last two come from the reconcile pass (src/lib/match/reconcile.ts): the text model receives all requirements plus the whole tag inventory at max reasoning effort, and its verdict is stored on the requirement — so the pure scorer honours it on every later recompute with no further model calls. It runs in the background; if it fails, requirements stay untouched and the built-in hierarchy still applies.

That is how Alex's résumé matches Microservices without ever using the word: the pass read "five FastAPI microservices behind an API gateway" and recorded the evidence.

literalHit searches renderedText(toTypstDoc(data)) — the exact strings Typst prints, with hidden bullets and excluded items removed. Hence the honest split between "in your tags" and "printed on résumé".

lock items covering a hard requirement  (+ newest education)
recommendSelection()   // greedy weighted set cover, soft reqs
mark lines naming a hard requirement as protected
  → AUTO_TAILOR_SYSTEM_PROMPT   (high effort, 180 s)
  → mergeAiReview()   // DROPS anything touching a locked
                      // include, a protected line, or an
                      // id/index that does not exist
  → fitToOnePage()
  → diffSuggestions(plan, target, base)

The plan is a pure function; the model only ever adjusts it, and its reply is filtered rather than trusted. A total model failure degrades to the tag-based plan plus a warning — never a broken selection.

The trim order is fixed and predictable: bullets of weak unlocked items → those items → unprotected bullets of locked items. The first bullet of a kept item is never removed, so no entry is reduced to a bare job title.

Overrides always win. Switch off a locked item and overrideWarnings explains the consequence in yellow instead of blocking you.

Reviews run fire-and-forget and are never awaited by a save. The route takes a per-user lock (meta/review.runningUntil), then reviews ≤ 24 items per request — selected first — in chunks of 6, two in parallel, at high effort inside a 260 s budget.

The parser (src/lib/review/parse.ts) is adversarial on purpose. A suggestion is discarded if it targets a field that does not exist for that section, if its current text is not found verbatim in the item, if the rewrite is empty, unchanged or bracketed — and, decisively:

// a rewrite may not introduce digits the original lacked
if ([...digits(proposed)].some(d => !known.has(d))) return null;

That one rule is what stops a language model from inventing "improved performance by 40%" on your behalf.

Staleness uses the same content hash as the tagger, so a review greys out and says so the moment you edit the text — rather than showing an old number as if it were current.

PDFs are rendered to JPEG in your browser by pdf.js before upload, because the vision model accepts text and image_url parts but rejects file parts outright. It is a Route Handler rather than a server action for two concrete reasons: server actions cap bodies at 1 MB, and the route needs maxDuration = 120.

Duplicate detection is not AI (src/lib/import/match.ts): canon lowercases, strips accents and punctuation, expands abbreviations (Sr., B.S., Ph.D.) and drops company suffixes; titles match on token Dice ≥ 0.8, and work experience additionally requires the same start year. Matches then merge — bullets and skill lists unioned, empty scalar fields filled.

Parsing is lenient by design: the envelope never fails, each item is validated on its own, and rejects become warnings shown in the review step instead of failing the upload.

Date-derived facts are local and instant: yearsOfExperience merges overlapping roles and excludes internships; employmentGaps counts from the first non-internship job. Only then does the model suggest the subjective fields — and it is never allowed to guess your location or work authorization. Suggested values stay visibly marked until you touch them.

The brief is regenerated only when the answers hash changes, and a failed generation keeps the old brief rather than leaving you with none.

It is read server-side only — the client never sends it — and every prompt that receives it appends CANDIDATE_CONTEXT_RULE: context for relevance and level, never evidence, never printed. Tagging and import do not receive it at all.

users/{uid}/meta/layout
  sectionOrder[]   // header always first
  itemOrder{}      // absent = order by date
  page             // margin mm · font pt · leading em
  sections{}       // above · below · itemGap · indent (pt)
  items{}          // spaceAfter · breakBefore · keepTogether

orderedItems (src/lib/layout/order.ts) is used by the editor, the library, the tailor window and toTypstDoc — so what you drag is what prints. The default is newest-first: current items, then latest end date, then latest start, undated last.

Writes use a plain set rather than a merge, because a merge would resurrect the very keys a reset was supposed to remove.

users/{uid}/variants/{id}
{ name, labels[],
  items:  { experience: ["exp-northwind", …], skills: […] },
  hidden: { "exp-northwind": ["…bulletKey…"] },
  layout: ResumeLayout | null,
  templateId: "ledger" }

Loading one is a single document read; applyVariantSelection then reads the current isSelected and hidden values and writes back only the documents that actually change.

Every id inside items must match [A-Za-z0-9_-]{1,128}, so a path can never be smuggled into a doc() call. Variants saved before layouts existed carry layout: null and leave your working layout alone.