The problem we're solving
Generic resume AIs invent things. "Spearheaded a cross-functional initiative that drove 47% growth." Maybe you did. Maybe the model just liked the cadence. By the time the recruiter calls, you don't remember which it was.
That isn't a polish issue. That's a fundamental trust break between the user and the tool. Once it happens once, every other thing the AI writes is suspect.
Dilly's position: the AI is allowed to write, but only against facts the user has put in the profile. Not against vibes. Not against generic resume templates. Against your actual record.
What the ledger actually is
A relational mapping, persisted alongside every Forge-generated resume, between each output bullet and the structured profile field that supports it. Conceptually:
| Bullet | Source profile field | Confidence |
|---|---|---|
| Led 15+ data science club members through weekly ML workshops, growing membership 60% in one semester. | experiences.president_data_science_club_utampa.metric:members + experiences.president_data_science_club_utampa.responsibility |
green · sourced |
| Architected a website redesign in HTML/CSS/JavaScript that lifted chapter engagement across 50+ active members. | experiences.chairman_tech_phi_upsilon.deliverable:website_redesign + experiences.chairman_tech_phi_upsilon.metric:active_members |
green · sourced |
| Drove $2M in incremental ARR through enterprise outreach. | , | red · unsourced (BLOCKED) |
The third row is the interesting one. The model proposed it. The ledger blocked it. The user sees the block in the UI: "We can't ship this bullet because there's no fact in your profile about ARR or enterprise outreach. Add one, or remove the bullet." The user is in control of which one happens.
How sourcing actually runs
At Forge generation time, the model is given the job description plus the structured profile, and asked to draft bullets. Each candidate bullet then runs through a sourcing pass:
- Span extraction. The bullet is parsed into claim spans (verb · object · metric · qualifier).
- Profile lookup. Each span is matched against profile fields using a structured index (not embedding similarity alone, the index requires actual field hits, not "rhymes with").
- Confidence assignment. A bullet earns green if every span maps to a field, amber if the high-level claim maps but specific numbers are model-supplied, red if no profile fact backs it.
- UI surfacing. Greens render normally. Ambers show a "verify this number" pencil. Reds are blocked from export with a 'no source' badge.
The model can be wrong. The profile is what we know. The ledger reconciles them in your favor.
What the user sees
In Forge, every bullet renders with a small source chip beneath it. Tap the chip and the supporting profile fields highlight, so you can see exactly where the claim came from. Tap a red badge and Dilly offers two options: "remove the bullet" or "add this fact to your profile so I can support it."
That second option is the magic move. The Truth Ledger doesn't just filter, it teaches the system. Every time a user adds a missing fact to support a bullet they liked, the profile gets richer, and tomorrow's resume is better at the next role.
Why it has to live in structured storage, not embeddings
We tried both. Vector similarity on its own is too forgiving. The model would write a bullet about "leading payments infrastructure," vector-match it against a profile note about "led the React Native sprint," and call it sourced. It wasn't.
The ledger uses embeddings as a candidate-finder, but the actual mapping requires a structured field hit (job, project, skill, certification, declared metric). Embeddings ride shotgun; the structured index is the gatekeeper. This is slower than pure vector search by ~80ms per bullet, well worth it.
What the ledger is not
- It is not a moderation layer for taste. The model still picks verbs, ordering, and emphasis.
- It is not a fact-checker against the world. It only checks against your declared profile.
- It is not opt-in. Every Forge generation runs through it. There is no "creative mode" that disables sourcing.
- It is not invisible. The chips are part of the artifact, when a user opens an old Forge resume, they can still see what each bullet was sourced from.
Why this matters at the system level
The Truth Ledger isn't an isolated Forge feature. It is the contract that lets the rest of the AI surface get more aggressive. Because every claim is sourced can quote from your profile, the chat can reference specific past projects without fabricating, and the fit narratives on jobs can name actual accomplishments rather than generic strengths. The whole system gets more grounded, not just one screen.
It also lets us ship a recruiter view, Blind Audition, where what surfaces is verified, sourced, and traceable. The recruiter clicks a bullet, sees the underlying profile fact, knows the candidate is real.
Roadmap notes
- Multi-source bullets. Today a bullet maps to one or two fields. Soon, when the model wants to combine three (e.g. project + metric + impact), all three must source independently.
- Cross-resume audit. If you generate two resumes for two roles, the ledger checks claim consistency across both, same fact, same number.
- Public-profile attestation. Optional. Sourced claims on your /p/your-name page get a small green dot showing they're traceable to real profile facts.
The bottom line
The Truth Ledger is not a feature. It is the rule that makes the AI usable. The user has to be able to look at any resume Dilly produces, find any line, and say "yes, that is mine." Anything less is a hallucinating resume tool with a friendly face.