SFI Foundation Web Modernization

1 Why SFI Certification Matters

The Hook

You have spent four months and most of your savings building a car. Race morning, tech inspection pulls you out of line: your harness is out of date and your fire suit's rating cannot be confirmed. You are not slow — you are not allowed on track. Somewhere in a binder is the spec that would have told you this in thirty seconds.

The SFI Foundation is a non-profit that writes and administers voluntary performance standards for motorsports equipment — helmets, harnesses, fire suits, head-and-neck restraints, bellhousings, flywheels. Manufacturers build to a spec, get tested, and earn the right to put an SFI label on the product. Sanctioning bodies then require those labels at the gate. The standards are the language the whole sport uses to talk about safety.

The labels a user has to decode

What is actually broken today

2 Overview & Learning Flow

Goal of the storyboard

This storyboard walks a user — and the build team — through one complete arc: from not knowing a spec exists, to finding it, to verifying a physical part against it, to being confident enough to sign off. Each section below maps to one stage of that arc, and each stage has a matching piece of software we are proposing to build.

flowchart LR
  A["Activation<br/>Why it matters"] --> B["Demonstration<br/>Guided lookup"]
  B --> C["Practice<br/>Fix a bad lookup"]
  C --> D["Application<br/>Scan and verify"]
  D --> E["Assessment<br/>Mastery check"]
  E --> F["Integration<br/>Ship to staging"]

The three things we are building

How the pieces connect

flowchart TD
  U["Racer / inspector / buyer<br/>on a phone"] --> N{"Home: 3 entry points"}
  N --> S["Search"]
  N --> V["Verify"]
  N --> B["Browse by category"]
  S --> EMB["Semantic ranking service"]
  EMB -.->|"unavailable or slow"| KW["Keyword fallback"]
  EMB --> D["Spec detail page"]
  KW --> D
  B --> D
  V --> CAM["Camera QR scan"]
  CAM -.->|"permission denied"| MAN["Manual code entry"]
  CAM --> LOOK["Certification lookup"]
  MAN --> LOOK
  LOOK --> R["Certified / Expired / Not Found"]
  R --> D

3 Case Studies

Activation — why the stakes are real

Before designing anything, the team studied why equipment standards exist at all. These are the cases we present to open the workshop.

4 Spec Lookup Workshop

Demonstration — the guided walkthrough

This is the instructor-facing part of the storyboard: how we demonstrate the tool live, what we say, and what we want the audience to notice.

Guiding questions we open with

• How would you find the right standard if you did not already know its number?
• What would convince you that a part in your hands is genuinely certified?
• What is the last thing you want to be doing on a phone in a hot pit lane?

Prototype assets to capture for the demo

Principles the demo must land

• A user can reach an answer without knowing SFI's internal vocabulary.
• Every verdict states plainly what it means and what to do next.
• No screen requires horizontal scrolling at 360px.
• Nothing is a dead end: denied camera falls back to typing, failed ML falls back to keywords.
• No raw error text or blank screen is ever shown to a user.

5 Practice: Fixing a Bad Lookup

Practice — the retrofit method

Most bad lookups fail the same way: the user searches a product name, gets nothing, and gives up. Here is the four-step method the interface is designed to teach implicitly.

1. Start from the object, not the number.Describe the physical thing and the context: "fire suit for drag racing," not "3.2A." Semantic search is built to accept exactly this.
2. Narrow by category, not by guessing.If the query is too broad, use the category filter as the second discovery path rather than retyping the query five times.
3. Read the rating suffix, not just the spec number.Two products can both be "SFI 3.2A" and offer very different protection. The detail page surfaces the suffix at the top, not buried in body text.
4. Verify the part, not the claim.A spec page proves the standard exists. Only a QR scan against the foundation's records proves this manufacturer holds it and it has not lapsed.

Worked example

6 Tooling & Ideation

Live prototype — try it in this page

Both tools below run entirely in this page against a small seed dataset. They are not the production system; they exist so the interaction model can be judged before a line of backend code is written. The ranking function here stands in for the embeddings service described in the ADR.

QR payload format

7 Small Groups & Feedback

Application — put it in users' hands

Groups of three, each given a phone and one of the three roles. Each group runs the same three tasks and records where they hesitate.

Deliberately flawed screen we show first

Speaker notes

• Do not explain the interface before they use it. Hesitation is the data.
• Record the first tap on the home screen for every participant — that tells us whether Search, Verify, and Browse really are equally weighted.
• Ask each group for one thing they expected to exist and did not find.

8 Rubric & Asset Capture

Evidence — before, plan, after

Every core flow is captured in three phases so progress is provable rather than asserted.

Wireframes captured for the "after" column

9 Mastery & Certification

Assessment — the done condition

This sub-issue is not "done" when it looks finished. It is done when all five conditions below hold at once, verified on a real phone.

1. All three features work end to end.Semantic search with keyword fallback, QR verification with all three verdicts, mobile-first UI across every core flow.
2. CI passes on main.Clean build on every push, no secrets in the repo, all environment-specific config behind environment variables.
3. A staging URL is live and shareable.Reachable by the Testing & QA and Deployment sub-issues without needing our machines.
4. A real user completes the arc on a real phone.Search a spec, get a correct result, scan a code, get a real-time verdict, navigate every flow with no unhandled error.
5. The ADR and known limitations are committed.Framework, hosting, and search provider documented before implementation; edge cases written up for handoff.

Sprint plan

Risks we are carrying

10 Summary & Key Takeaways

Integration

Problem statement. Users need a fast and reliable way to search SFI safety specifications and verify manufacturer certifications on mobile devices, because the current experience is hard to navigate, slow to search, and not optimized for modern verification workflows.

Success statement. We know this works when users can find the correct spec in seconds, scan a QR code to verify manufacturer certification in real time, and complete key tasks easily from a phone without support help.

Scope boundaries

Dependencies and handoffs

• Blocks: Testing & QA cannot begin full test execution until this reaches a feature-complete staging build.
• Blocks: Deployment cannot promote to production until Testing & QA signs off on this build.
• Depends on: nothing — this is the foundational build sub-issue.

Task breakdown

• Write and commit the architecture decision record (framework, hosting, search approach)
• Scaffold the project (repo, linting, formatting, CI build check)
• Build the shared design system and base layout components
• Ingest and normalize the spec dataset
• Build baseline keyword search: search bar, results list, spec detail page
• Integrate the ML/semantic layer with keyword fallback
• Add category filtering and the browse view
• Define the QR payload format and seed certification test data
• Build the QR scan flow: camera access, permissions, error states
• Build certification lookup and the three verdict screens
• Build the mobile-first home page and primary navigation
• Implement responsive behavior across mobile, tablet, and desktop
• Run and resolve the baseline accessibility pass
• Deploy the feature-complete build to staging
• Document known limitations and edge cases for Testing & QA

Team approval