Method · Product Qualification & Decision
How it decides
One requirement, seven stages: place it on the car, extract what was asked, disqualify what cannot work, score what is left, cite the source for every claim, translate the fit into customer value, and write the decision — including what it refuses to answer.
13 of the 23 sections of the qualification document are computed from public sources. The rest need customer, pipeline or pricing data this project does not have — those are marked, not filled in.
One requirement moves through these in order. Each stage is a page, and each page answers exactly one question — so “why is there a separate tool for that?” has an answer other than “it seemed useful”.
- 01Where it sits
Which vehicle function are we qualifying for?
Places the requirement on the car and names the leading device for that socket.
Architecture → - 02What was asked
What exactly did the customer require?
Extracts the RFQ into numbered requirements, each quoting the customer and carrying a must/should/nice priority.
Qualification → - 03What disqualifies
Which candidates fail a hard constraint?
Applies hard gates — a missing must-have interface or ASIL level is out at any score, never averaged away.
Qualification → - 04What fits best
Among the survivors, which scores highest, and why?
Scores every eligible device on weighted factors, each factor carrying its own reason.
Qualification → - 05What proves it
What public source backs each claim?
Attaches a cited source to every claim, and says verify — not a number — where the public data is silent.
Qualification → - 06The decision
What do we recommend, and what do we refuse to answer?
Emits the decision record — or 'no validated match' plus the exact gap that blocks one.
Qualification → - 07What it's worth
Why does the customer care, and who else is bidding?
Turns technical fit into customer value, names the competition, and sets the design-win action.
Market & GTM → - The shape of it
One requirement, seven stages: place it on the car, extract what was asked, disqualify what cannot work, score what is left, cite the source for every claim, translate the fit into customer value, and write the decision — including what it refuses to answer.
How it works →
The qualification document has 23 sections. This is what this project can put in each one, and where it comes from. A section marked needs internal data stays empty on purpose: an estimated price or an invented design win would be worse than a blank.
| § | Section | Where it comes from | Source |
|---|---|---|---|
| 1 | Document control | You fill this | Account, platform, SOP target and version — typed by you. |
| 2 | Decision objective | Method | Fixed by the method: best fit, hard gates separated, evidence shown, gaps named. |
| 3 | Customer problem statement02 | You fill this | The customer's own words, plus your normalization of them. |
| 4 | Requirement extraction02 | Computed | lib/extract.ts → normalized requirement lines with priority, threshold and a verbatim quote. |
| 5 | Safety03 | Computed | Required ASIL versus each candidate's published maximum, with the evidence level. |
| 6 | Cybersecurity03 | Computed | HSM and post-quantum capability as published per series, with its evidence level. |
| 7 | Product shortlist04 | Computed | lib/scoring.ts → the highest-scoring candidates, each marked eligible or disqualified. |
| 8 | Hard-gate compliance03 | Computed | lib/compliance.ts → every must-have requirement against every shortlisted candidate. |
| 9 | Weighted score04 | Computed | The weighted factors, each with its reason. Two of the document's dimensions are gaps — see below. |
| 10 | Feature → benefit → value07 | Computed | Published key features joined to the scoring reason that made each one matter here. |
| 11 | Customer-specific value proposition07 | You fill this | How you would say it to this account. The tool supplies the evidence, not the pitch. |
| 12 | Architecture position01 | Computed | lib/vehicle/ → where this function sits in the vehicle and what it talks to. |
| 13 | OEM / Tier-1 influence map | You fill this | Named people and their influence. CRM data — this project has none, and will not invent it. |
| 14 | Design-win stage07 | You fill this | Your stage, with its evidence. The Mapper suggests the next action; only you know the stage. |
| 15 | Competitive battlecard07 | Computed | data/competitors.json → published competitor parts and shares, each with a source. |
| 16 | Commercial worksheet | Needs internal data | ASP, NRE, tooling and licence costs are not public. No price is ever estimated here. |
| 17 | Risks / unknowns05 | Computed | Every escalation reason, plus every requirement the public data cannot confirm. |
| 18 | Evidence register05 | Computed | Every source cited by this record — series pages, the product brochure, retrieved passages. |
| 19 | Final decision06 | Computed | The recommendation, or 'no validated match' plus the exact gap that blocks one. |
| 20 | AI output contract06 | Computed | The whole record as the JSON the document specifies, for a downstream system. |
| 21 | Guardrails05 | Method | The ten rules, quoted, beside the code that enforces each one. |
| 22 | Build backlog | Method | The document's own work packages, and which of them this project has built. |
| 23 | Notes | You fill this | Anything else you want on the record. |
Section 21 of the document, quoted. A rule nobody can point at is a slogan, so each one names the module that keeps it — or says plainly that nothing automatic does.
- 01
Never fabricate missing specifications.
Specs come only from the transcribed public portfolio. A spec the source does not state is null, and renders as 'verify' — never as a zero or an average.
data/aurix-portfolio.ts, lib/compliance.ts
- 02
Never generalize a derivative feature to a whole family without evidence.
Every capability carries an evidence level: stated on the series page, stated only at family level, inferred, or not listed. The last three read as 'verify' in the matrix.
SupportLevel in lib/schemas.ts, lib/compliance.ts
- 03
Never equate “supports ASIL-D” with “the whole system is ASIL-D.”
The catalog records the maximum ASIL a device supports. The compliance matrix compares that against the requirement; it never asserts a system safety level.
lib/compliance.ts
- 04
Use ISO 26262 for functional safety and ISO/SAE 21434 for automotive cybersecurity.
Safety is expressed as ASIL levels and security as published HSM / post-quantum capability, each with its evidence level.
— no automatic check; kept by data curation and review
- 05
Never claim market leadership without evidence.
Two different claims are kept apart by name: 'leads (fit)' is rank one in this project's own scoring of public specs; 'leads (market)' is the highest sourced share. They are never merged.
lib/segments/position.ts, lib/market/share.ts
- 06
Never name a customer/design win without an authoritative source.
The only fabricated file in the repo is the demo account list, which is quarantined: no pure module may import it, and every view of it carries a mock banner.
data/demo-accounts.ts, the gate's import check
- 07
Never estimate price without labeling basis and confidence.
No price or lead time appears anywhere — they are not public. Cost is a relative positioning proxy, labelled as ours, and the commercial worksheet is a declared gap.
lib/catalog.ts, lib/pqd/sections.ts
- 08
Never choose on compute alone; match the workload.
Spec fit weighs compute, memory and I/O, and marks down over-specification as well as shortfall. Application fit weighs which segment matched, so a broad umbrella hit scores below specific positioning.
lib/scoring.ts
- 09
Always show evidence, confidence and trade-offs.
Every factor carries its own reason, every requirement its status and source, and every ruled-out candidate the constraint that ruled it out.
lib/scoring.ts, lib/compliance.ts, lib/pqd/build.ts
- 10
Escalate confidential, safety, roadmap and commercial questions when evidence is insufficient.
Out-of-scope, too-vague and weak-fit requirements stop before a recommendation is written, and the chat explains the escalation rather than overriding it.
lib/guardrails.ts
Section 22 of the document is a build backlog. This is an honest read of it — “partial” means the work package exists but rests on public data where the document expects internal data.
- P0Product databasebuilt77 public devices, verbatim key features, each with its cited source.
- P0Requirement parserbuiltExtraction is validated at the boundary, then normalized deterministically.
- P0Hard-gate matcherbuiltMet / verify / not-met / manual — 'unknown' is a real outcome, not a pass.
- P0Evidence enginebuiltEvery spec names the public source it was read from.
- P1Market mapperbuilt22 applications × 77 devices, with stance and lever.
- P1Competitive databasepartialPublic competitor parts and shares only; no win/loss history.
- P1Design-win plannerpartialActions are computed; accounts and stages are mock or operator-entered.
- P1TCO modelnot builtNeeds non-public pricing. Declared a gap rather than estimated.
- P2Feedback looppartialFailures become golden scenarios and eval cases, but there is no in-app correction UI.
- P2DashboardpartialPortfolio-level scoring and market position exist; pipeline analytics need CRM data.
Four pages are numbered stages of one decision. The others carry no stage number: they answer a portfolio question upstream of any single request, track decisions across deals, or explain the method.
- 01Vehicle ArchitectureEvery application placed on the car, with the leading AURIX device for each socket.Everyone — the one-screen story
- 02–06RFQ QualificationAn RFQ becomes requirements, hard gates and a scored shortlist you can interrogate.FAEs & sales engineers
- Competitive LandscapeEvery AURIX device against the competitor families that contest the same sockets, on thirteen dimensions.FAEs, BDMs & product managers
- 07Market & Go-to-MarketOne product family: where it stands, where to play, the gaps, and the go-to-market plan — every claim sourced.Product managers, BDMs & marketing
- Design-win CRMAccounts, people and design-in opportunities, each tied to the AURIX parts the Navigator scored. Fictional demo data.FAEs, sales & BDMs
- MethodologyThe PQD process, which sections are computed, and the guardrails that stop a guess.Anyone asking how you know