How it's built · an agentic project ·
July 2026

A scoring engine, built and run by an AI agent

Six steps, in order. Each stands on its own — the accountability does not depend on finishing the rest. Written for any reader, technical or not: every section below describes what the system actually does, not an idealized version of it.

Field note

An early version of the pricing model priced nearly every Business class round-trip at the same figure, regardless of route or carrier: a rounding floor was overriding the variation built into the model. Step 03 exists because a recommendation is only as trustworthy as the numbers behind it. The error was found by running the engine end-to-end and reading the output, not by reviewing the code alone.

01Tools & mode

Built entirely in Cowork, with no terminal involved, by design. The Input Card, scoring engine, and every output section run as plain JavaScript in your browser. Nothing you type is sent anywhere — the system collects no data because it has nowhere to send it.

Chat
decide
  • weighting model for the 7 priorities
  • reference-range values (fares, miles)
  • what "genuinely strong" means for a redemption
Cowork
build & maintain
  • the scoring engine (app.js)
  • every static page, end to end
  • Netlify deploy
Your browser
run the model
  • reads your Input Card
  • computes scores locally
  • nothing transmitted
Phase 2 (planned)
live data
  • real fare search
  • real award availability
  • see Roadmap, phase 05
Chat decide weighting model reference ranges redemption bar Cowork build & maintain scoring engine every static page Netlify deploy Your browser run the model reads Input Card computes locally nothing transmitted Phase 2 live data (planned) real fare search real award data Roadmap, phase 05 no terminal in this stack — Cowork carries the build role, the browser carries the run role
Which mode carries which responsibility.
02Reference ranges, not a live search — and labeled as such

Every fare shown is generated from a per-cabin base price plus a variation for stops, fare tier, and date flexibility — a planning model, not a fetched quote. Every mileage figure comes from hand-maintained round-trip ranges by cabin (Business, for example, runs roughly 115,000 to 320,000 miles plus taxes and fees) — the kind of range a knowledgeable advisor would quote from memory before checking live availability. Upgrade-friendliness scores are a general reputation judgment per carrier, not a live seat map. Nothing here is presented as a live quote. The homepage banner says so directly, and this page states which numbers are computed versus referenced.

03Six dimensions, weighted by your ranking — never a single variable

Every candidate itinerary is scored 0 to 100 on Cost, Comfort, Upgrade Potential, Award Value, Flexibility, and Risk. Your ranked priority list, from Cheapest to Best Overall Experience, maps onto those six dimensions through a fixed weighting table: a rank-1 priority carries more weight than a rank-7 one. The final score is a weighted sum, shown on the results page as an explicit percentage per dimension, so the reasoning behind the recommendation is never reduced to a single number.

Always shown

The exact weight (as a %) each of the six dimensions received, computed live from your priority ranking — not a fixed default.

Never done

Optimizing for price alone. A cheaper itinerary that scores meaningfully worse on your higher-ranked priorities will not out-score the better-rounded one.

04A model, not a live connection

As with the other systems in this portfolio, this one states plainly what's real. It does not connect to Google Flights, ITA Matrix, seats.aero, or any airline system. Every number is either computed from your inputs in real time or drawn from a hand-maintained reference range. Running the same inputs twice produces the same result — the model is deterministic by design, not randomized.

05Static deploy today, GitHub + Netlify Functions next

This build ships as static HTML, CSS, and JavaScript to Netlify. No backend is required for a scoring engine that runs entirely in the browser. A GitHub repository will mirror the other sites' deployment model — push to main, Netlify deploys automatically — and becomes the foundation for Phase 2's live data functions once those are approved and built.

Claude / Cowork builds & pushes to GitHub GitHub repo, main branch Netlify auto-deploy on push Your browser runs the engine locally no server round-trip once the page loads — the scoring engine ships as part of the static bundle
The real deploy path today.
06What's still manual — and what's still missing

Live fare and award data is the largest remaining gap — everything shown today is a documented model, not a search result, and closing that gap is the entirety of Phase 2. Any further real spend, such as paid API keys, still requires Susan's explicit approval first, the same rule the other two sites operate under. There is also no saved-preference memory yet, so every session starts from the same defaults instead of recalling a prior trip's inputs.

What this took to learn

A recommendation is only as trustworthy as the labels on its numbers. Presenting a reference range as a live quote would be worse than not building the feature at all.

Authorization precedes any expenditure. A domain name, a paid API key, or any real spend is a decision left to Susan, never delegated.