Pathfinder 2.0, audited against itself
The design system for AVANT's partner portal, run through the nine skills from the library, with the findings written down, including the five things that are wrong. Every count on this page came out of the shipped source.
What the system is for
AVANT's partners log into the portal to run their business: pipelines, orders, analytics, reporting. The screens are dense and dark, and there are a lot of them. Pathfinder's job is to keep them consistent enough that a partner doesn't relearn the interface on every page.
The second job is maintenance. One person owned the system, working with three engineers and a PM, so anything that needed that person in the room to stay correct was going to rot.
Count what's actually there
This step is a grep, not a guess. The stylesheet declares 1,146 custom properties. Here is how they split.
The homepage says one, the stylesheet ships the other. Either is arguable depending on what you count. Publishing one and shipping the other isn't.
The stat row and the card forty pixels below it disagree. Nobody downstream can quote the system's own size.
Five findings, each with a file behind it
The severities are a judgment call. The evidence isn't. Each one names where it lives, so the team can argue about the ranking without arguing about the facts.
Name the alias layer as the public API and mark tier 2 internal. Then generate the contrast table from the tokens it describes.
That clears the first finding, turns the third into a scoped build task, and makes the accessibility claim something a release can fail on. The cleaner option, moving all 29 components onto tier 2, takes weeks and no partner would see a difference.
How people actually move through it
Pathfinder ships a map of itself, and the part worth keeping is that the arrows are typed. If every line on a diagram means the same thing, it can't tell you what breaks when you change a token.
The map encodes a path: learn the cascade, use components, compose patterns, build dashboards. That is also the order in which a new engineer stops asking questions. That's the only adoption signal this artifact supports, and it's a soft one.
Type and contrast are part of the library
Five roles carry the whole portal, shown here in their own faces. The rule that does the most work is the last one: every number, ID and timestamp is monospaced, which is what makes a dense table scannable.
- Status never travels by color alone. Every semantic fill gets a label or an icon.
- An error says what happened and what to do next. "Something went wrong" is a bug, not a string.
- Numeric columns are monospaced, right-aligned, one unit per column.
- Contrast pairs are generated from their tokens and block the release when they fail.
- Focus stays visible at 2px in both themes, checked in light mode too.
The three best arguments against this work
Six releases, dated, with the breakage written down
The strongest governance evidence in Pathfinder is its release record. It's versioned, dated, and specific about what changed. This part transfers to a client system unchanged.
Semantic, field, shell, chart, avatar and indication colors land together. Nav grows to five sections and 29 items.
Badge, notification, avatar, tabs, and an eight-state input playground. Two fixes logged against named tokens rather than "polish".
Six preset layouts assembled from the library, for showing a stakeholder that the parts fit together.
Motion becomes tokens: durations and easing curves. Spacing renamed to match the platform convention.
Disabled text brought up to AA Large, focus width unified at 2px, one token deprecated with its replacement named.
Four foundations, the core components, and theme switching by data attribute from the start rather than retrofitted.
What to instrument, and the rule set before the first reading
A case study usually ends with a percentage here. There isn't one for Pathfinder that can be sourced, so it ends with the part that transfers instead: the instrument, and what is agreed about the result before anyone sees it. Agreeing afterward is how a metric ends up decorating a decision that was already made.
| Metric | Instrument | Rule, agreed in advance |
|---|---|---|
| Token coverage | Lint for raw hex and px in component source | A new literal fails the build. Existing ones go on a dated list that only shrinks. |
| Theme parity | Tokens the light theme overrides, against the total | Published as a number. Below the agreed floor, "2 themes" comes off the homepage. |
| Contrast | Ratios computed from tokens at build time, both themes | A pair under its target blocks the release. |
| Adoption | Imports of library components per release, by repo | Flat while releases keep shipping means the library is being read, not used. That stops feature work until it's understood. |
| Patterns per problem | A quarterly re-run of the inventory in section 02 | Two implementations of one problem becomes a ticket with an owner and a date. |
| Support contacts | Partner tickets tagged with the pattern vocabulary | Whatever generates the most contact is next. It's the cheapest research the business already pays for. |
Four open questions
Count it, cite it, say what you don't know
Dense B2B software rewards the same few habits. Inventory before you propose anything. Attach a file to every finding so the argument stays about the work. End on an instrument rather than a number you'd have to defend. The skill library is that method written down, and this page is what happens when it is pointed at its author's own system.