How Idynic thinks.
Idynic keeps your career as evidence, not as a document. This is a walkthrough of the machinery underneath: what each part does, which model runs it, and the rules we hold it to.
Every score is a stack of small, inspectable judgments
A job posting is not a keyword list. We read it into a ledger of requirements, each one marked must-have or nice-to-have and given a stable identity, so the same requirement can be re-judged later and compared against its own history.
Then each requirement is judged on its own, against your record. Here is one, rendered the way the system holds it:
- Built and led the field engineering org through two platform migrationsrank 0.86achievement · resume · confidence 0.83
- Owned the escalation path between support and platform teamsrank 0.71achievement · story · confidence 0.64
- Customer success toolingrank 0.38skill · inferred · confidence 0.25
Two independent records show direct ownership of a customer-facing engineering org. Contributes 1.0 at must-have weight.
Illustrative record. The retrieval rank, the provenance, the confidence figure and the verdict are all real fields, and you can open any of them in the product.
5 candidates per requirement
Search finds candidates. It never decides.
Every claim carries an embedding, and we use vector similarity to pull the handful of records most likely to bear on a requirement. That is the entire job of the embedding: topical proximity is not proof, and a number that measures how related two sentences sound must never be mistaken for a judgment about whether someone can do the work.
So similarity only ranks the shortlist. Ranking blends it with how well-evidenced the claim already is, and nudges concrete achievements above bare skill tags, because a tagged keyword should not outrank a described accomplishment just because the wording is closer.
The decision itself is made by a language model reading the requirement against the shortlisted records as prose, and returning one of three verdicts with its reasoning attached. It can say met, partial, or unmet, and partial carries real weight: when a record has the substance of a requirement but not a narrowing qualifier it names, that is half credit, not zero.
0.5 ^ (years / half-life)
Evidence ages, and not all of it ages alike
Every claim in your record links back to the evidence that produced it, and carries a confidence figure derived from two things: where it came from and how long ago.
| Source of evidence | Weight | Why |
|---|---|---|
| certification | 1.5 | Verified by a third party |
| resume | 1.0 | The professional record, our baseline |
| story | 0.8 | Told to us directly. Valuable, unverified |
| inferred | 0.6 | Derived by the system, not stated by you |
| Repository | 0.5 | A dependency in a file is weak proof of depth |
| agent-digest | 0.3 | Grounding from connected activity. Never imported as evidence |
Decay is exponential, and the half-life depends on what kind of claim it is. A framework you last touched six years ago is genuinely staler than a result you delivered six years ago, and neither is as durable as how you work.
| Kind of claim | Half-life | Why |
|---|---|---|
| Tool or framework skill | 4 yrs | Tooling turns over fast |
| Achievement | 7 yrs | Results stay relevant longer |
| Attribute | 15 yrs | How you work is durable |
| Education | no decay | Degrees do not expire |
| Certification | no decay | Credentials are permanent |
| Competency-level skill | 15 yrs | Architecture, leadership, strategy |
Splitting skills by altitude matters more than it sounds. Counting evidence alone cannot tell “mentioned across twenty dependency files” apart from “led the organization through it”. Without the split, tool-level noise outranks the competencies that actually describe a career.
met 1.0 · partial 0.5 · unmet 0
One number, and the arithmetic behind it in full
Verdicts become a score by the plainest arithmetic we could defend. Must-haves carry 70 percent of the weight, nice-to-haves 30, and each verdict is worth exactly what it says.
We keep it this legible on purpose. A match score that a person cannot reconstruct by hand is a score they cannot argue with, and every requirement stays open. You can read the verdict, the reasoning, and the records it rested on, and you will find the gaps the same way we did.
What happens after you upload
The order matters, so here it is as an order.
- 01
Ingest. Your resume or document is read in a single pass with your existing record already in context, extracting evidence, work history, contact details and candidate claims together, so nothing is interpreted in isolation from what we already know about you.
- 02
Claims and evidence. Extracted facts become claims linked to the passages that produced them. Duplicate employers merge on company and dates, keeping the more precise dates and the more specific title.
- 03
The corpus. Your claims, work history, projects and stories are assembled into one career record, the single body of text everything downstream reasons over.
- 04
The requirement ledger. A job posting is parsed into individually addressed requirements, typed must-have or nice-to-have.
- 05
Adjudication. Each requirement is judged against the corpus and its verdict is stored with its reasoning, so a score can be explained later and compared as your record grows.
- 06
Documents. A tailored resume and letter are assembled from what was actually selected, ordered by relevance to this role, never by which section happened to come first.
embeddings: 1536-dimension
Which model runs what, and why that one
24 distinct operations each get their own model assignment, tiered by what it costs to be wrong. Every one is overridable per deployment, so a model choice is a setting rather than an assumption baked into the code. This table is generated from the configuration of the deployment serving this page.
claude-opus-5The single pass that reads a document into your record. Mistakes here propagate into everything downstream, so it gets the heaviest model we run.
ingest_engine
claude-sonnet-5Anything a person reads, or that gates a score. Graders sit in this tier as a rule: the model checking the work is never weaker than the model that did it.
compute_system_match · judge_application · generate_base_resume · generate_resume · generate_narrative · generate_talking_points · generate_qa_drafts · generate_recruiter_summary · generate_repo_story · generate_search_preferences · claim_eval · tailoring_eval · research_company · rewrite_content · reflect_identity · extract_opportunity · extract_email_jobs · extract_preferences · connector_digest
claude-haiku-4-5-20251001Cheap, frequent calls that only sort signal from noise. Failure costs a mis-filed row, not a lost opportunity, and these paths fail open.
score_intake_relevance · chat_copilot · chat_title
whisper-1Spoken stories transcribed before they enter the record as evidence.
transcribe_audio
text-embedding-3-small1536-dimension vectors over your claims. Used to shortlist candidates, never to score them.
match_identity_claims
How we think
Evidence before assertion
Every claim traces to something you supplied. The system expands your words into prose; it does not invent facts to fill a gap. A hole in the record stays visible until you fill it.
Selection in code, prose from the model, verification in code
What goes into a document is chosen deterministically. The model writes it. Then code checks the result for length, structure and banned phrasing, and rejects it if it drifted. Judgment is delegated to the model; the contract is not.
The grader is never weaker than the generator
Anything that evaluates output runs at or above the tier of the thing that produced it. A cheap grader over an expensive generator is just a rubber stamp.
A test case is a specification
We keep a graded set of judgments with known correct answers. When the system disagrees with one, the calibration is what is wrong, not the answer key. Editing the expectation to make a check pass is the one shortcut we never take.
Undercredit is a failure too
It is easy to gate only on inflated scores, because inflation is embarrassing. But a system that quietly under-reads your record costs you interviews and you would never see it happen. Both directions fail the check.
Never bind a duration to a technology
Twenty-six years of engineering does not mean twenty-six years of a cloud platform that did not exist for most of them. Time claims attach to the career, never to the tool. A single sentence like that discredits an entire resume, and a reader is right to stop there.
Your edits survive regeneration
When you remove or rewrite something, that decision is recorded against the specific line you changed. Regenerating the document reapplies your edits rather than overwriting them, and a removal never takes a similar-looking sibling down with it.
Nothing is capped for tidiness
We do not drop skills or history to hit a length target. If a recruiter filters on a term you genuinely have, it needs to be there. Emphasis and ordering are how a document handles relevance; deletion is not, and truncation belongs to whatever is rendering the page.
What it will not do
It will not write you a career you did not have. Every line in a tailored document is a reframing of evidence already in your record, which is why the tailoring gets sharper as you feed it more and stays honest when you do not.
It will not apply anywhere on your behalf, and it does not share anything until you create a link and send it yourself.
And it will not pretend a match is better than it is. When a requirement is unmet, the score carries the gap and the document does not volunteer it. The reasoning is there for you to read, and what you do with a seventy-percent match is your call, not the system’s.
Model assignments, weights and half-lives on this page are read directly from the running configuration and the constants the scoring code uses. They change as we calibrate, and this page changes with them.
Looking for the plain-language walkthrough instead? Start with /trust.