Building Navi: Inside Inlet's AI-Native Compliance Engine
How we built a compliance engine that processes 30,000+ ingredients against 4,000+ regulations in under a second — and why 95% of checks never need AI.
Introduction
At the core of any regulatory compliance company is its compliance engine — the system that takes a product formulation and determines whether it can be legally sold in a given market. For cosmetics and food & beverage, this means checking every ingredient against thousands of regulations: banned substance lists, concentration limits, labeling requirements, nano-material declarations, and claims restrictions.
This process has historically been manual. Regulatory affairs teams maintain spreadsheets of ingredient restrictions per market, cross-reference government databases by hand, and rely on external consultants at $300-500/hour to validate formulations. A compliance review for a single SKU in a single market can take days. Across a portfolio of 100 products targeting 5 markets, the cost runs into hundreds of thousands of dollars annually.
We built Navi to bring that cost toward zero. Navi is not a legacy compliance tool with AI bolted on — it's an AI-native engine designed from the ground up to handle the full spectrum of regulatory questions, from trivial lookups to ambiguous edge cases that require genuine reasoning.
This post walks through how Navi works: the 3-layer compliance pyramid, the data pipeline that feeds it, the ingredient matching system, and the expert review workflow that keeps it honest.
System Overview and Architecture
At a high level, Navi sits between the global corpus of regulatory materials and the products our customers need to bring to market. When a user runs a compliance check, Navi evaluates every ingredient in a product against every applicable regulation for the target market, then produces a structured report with pass/fail determinations, confidence scores, violation details, source citations, and suggested remediations.
The key architectural insight: not all compliance questions require the same level of sophistication to answer. An ingredient that's banned in the EU (like Formaldehyde above 0.1% in cosmetics) doesn't need AI — it needs a table lookup. An ingredient that's permitted in the US but restricted in Canada to specific product categories needs conditional logic. And a novel ingredient with no regulatory history needs genuine reasoning.
We structured Navi as a pyramid with three layers, each handling a different class of question:
Banned substances, concentration limits, required warnings, nano labeling. Pure computation — no LLM calls, no ambiguity.
Context-dependent rules: product category, age group, rinse-off vs leave-on, sub-regional requirements. Decision trees with branching conditions.
Novel ingredients, ambiguous claims, cross-border edge cases. LLM-powered reasoning grounded in retrieved regulatory context.
This pyramid design means AI is only invoked when deterministic methods can't answer the question. The result: 95% of checks complete with no LLM calls, keeping costs low and latency sub-second. When AI is needed, it receives curated context from the regulatory database — not the entire corpus — so reasoning is focused and grounded.
Layer 1: Deterministic Rules
The deterministic rule engine is the workhorse of the compliance pyramid. It handles the 80% of checks that have unambiguous answers: is this ingredient banned? Is the concentration over the limit? Does the regulation require a specific warning label?
For each ingredient in a SKU, the engine queries our ingredient_regulations table to find every applicable rule in the target market. Each rule has a status (prohibited, restricted, or permitted), an optional maximum concentration, product type restrictions, and required warnings.
The engine runs six checks per ingredient:
If the ingredient_regulation status is 'prohibited', the check fails immediately with confidence 1.0. No exceptions, no gray area — a ban is a ban.
Example: Formaldehyde in EU cosmetics (EC 1223/2009 Annex II)
Compare the SKU's ingredient concentration against the regulation's max_concentration_pct. If the product contains 1.5% Salicylic Acid but the EU limit is 2.0%, it passes. At 2.5%, it fails.
Example: Salicylic Acid in EU: max 2.0% in cosmetics, 3.0% in rinse-off
Some ingredients are only permitted in certain product categories. Hydrogen Peroxide is allowed in hair dyes but not in skin care. The engine checks the SKU's category against the regulation's product_type_restrictions list.
Example: Hydrogen Peroxide: permitted in hair products, restricted in skin care
When a regulation mandates specific label text (e.g., 'Contains fluoride'), the engine flags required_warnings. This doesn't block the product — it ensures the label is compliant.
Example: 'Contains fluoride — children under 6 should use a pea-sized amount'
The EU and ASEAN require nano-sized ingredients to be declared on the label with '[nano]' suffix. The engine checks sku_ingredient.is_nano against market-specific nano labeling rules.
Example: Titanium Dioxide [nano] in EU sunscreens
If an ingredient has no regulatory links for the target market, the engine flags it as 'needs review' rather than passing silently. Better to surface unknowns than to miss a restriction.
Example: Novel biotech-derived peptide with no FDA history
Each check produces a CheckResult with a status (pass, fail, warning), confidence score, violation detail, citation to the source regulation, and suggested remediation. The engine also handles the distinction between rinse-off and leave-on products — a shampoo and a moisturizer containing the same ingredient may have different concentration limits.
Layer 2: Conditional Logic
Some regulations can't be evaluated with a simple lookup. They depend on context that isn't captured in the ingredient_regulation table alone: the product's intended use, the target age group, the specific sub-region, whether the product is classified as cosmetic or drug.
Layer 2 implements rule trees — structured decision graphs where each node evaluates a condition and branches to sub-rules. We encode these as Python classes that receive the full product context and return structured results.
When conditional logic kicks in
The EU sunscreen regulation is a good example. SPF claims are permitted, but the regulation imposes specific requirements based on the UV-A protection ratio. A product claiming SPF 50 must also achieve minimum UV-A protection. This can't be determined by looking at ingredients alone — it requires evaluating the claim in context.
California Proposition 65 is another case. An ingredient that's permitted at the federal level (by FDA) may still require a warning label in California if it appears on the Prop 65 list. The conditional engine checks both the federal jurisdiction (US) and sub-jurisdictions (US-CA) to catch state-level requirements.
Conditional results carry confidence between 0.75 and 0.95. The lower bound reflects the inherent judgment calls in product classification — is a tinted moisturizer with SPF 30 a "cosmetic" or a "drug" under FDA rules? The answer affects which regulations apply.
Layer 3: AI Reasoning
When deterministic and conditional rules can't resolve a question, Layer 3 invokes Navi's AI reasoning model. This happens for roughly 5% of checks — novel ingredients with no regulatory history, marketing claims that sit in a gray area, and cross-border edge cases where regulations conflict.
The same as a human regulatory consultant, Navi's reasoning must be grounded in actual regulatory text — not general knowledge. We achieve this by retrieving relevant regulation sections from our database and injecting them into the model's context window.
Context assembly
For each AI check, Navi assembles a context package:
- The specific ingredient or claim under review
- The target market and all applicable jurisdictions (including sub-regions)
- Retrieved regulation text — the full_text field from matching regulations, not summaries
- Product metadata: category, form factor, intended use, other ingredients
- Results from Layer 1 and Layer 2 (to avoid re-evaluating settled questions)
We use Anthropic's Claude for reasoning. The model produces structured assessments with a determination, confidence score, reasoning chain, citations to specific regulatory sections, and suggested remediation. Every AI determination is labeled as such in the UI and flagged for expert review.
Data Collection
Navi's accuracy depends entirely on the quality and freshness of its regulatory data. If a regulation changed last week and our database still reflects the old version, we'll produce wrong results with high confidence — the most dangerous failure mode.
We maintain 12 automated regulatory agents that monitor authoritative government sources across cosmetics, food & beverage, and US state/local jurisdictions. Each agent understands the structure of its source — from well-indexed APIs like the eCFR to unstructured PDF annexes — and extracts structured regulation records on a continuous basis.
Together these agents cover 40+ jurisdictions: US federal, 26 US states, EU (plus 5 member states with national-level rules like France's PFAS ban and R-nano registry), UK (with its post-Brexit divergences from EU rules), Canada (federal + Quebec), Japan, South Korea, Malaysia, Singapore, Australia, New Zealand, and Codex Alimentarius international standards.
The regulatory agent pipeline supports two modes. In guided mode, a domain expert oversees the extraction for complex sources like multi-page PDF annexes where document structures vary — a single Prop 65 listing notice might reference five different chemicals with different effective dates. In autonomous mode, agents run continuously for well-structured sources like the eCFR API, detecting and ingesting changes automatically.
Every scraped regulation flows through a three-stage pipeline: fetch (pull the raw document with rate limiting and deduplication), extract (Claude parses the document against a source-specific schema to produce structured regulation, ingredient, and ingredient-regulation link records), and stage (records land as review_status='draft' for human approval before they become active in the compliance engine). Nothing enters the production rule set without a reviewer sign-off — the cost of a wrong auto-ingestion (falsely flagging a product as non-compliant, or worse, missing a real violation) is too high to skip the checkpoint.
Jurisdiction data is stored hierarchically — "US" for federal, "US-CA" for California, "EU-FR" for France. When a customer runs a compliance check for the US market, Navi uses a single LIKE-based query to pull federal regs alongside every US-* state rule in one pass. That means a product formulated for the US market is automatically evaluated against Prop 65 warnings, New York's 1,4-dioxane limits, Washington's lead cap, Hawaii's oxybenzone ban — without any separate configuration from the user.
Normalization and Indexing
Raw regulatory data from government sources is messy. Ingredient names aren't standardized across jurisdictions. The EU uses INCI nomenclature, the FDA uses common names, Health Canada mixes both. A single ingredient might appear as "Sodium Lauryl Sulfate" (INCI), "SLS" (abbreviation), "Sodium dodecyl sulfate" (chemical name), or CAS 151-21-3 (registry number).
Our normalization pipeline resolves these to canonical INCI names, then creates bidirectional links between ingredients and regulations. Each ingredient_regulation record captures the relationship: which ingredient, which regulation, what status (prohibited, restricted, permitted), what concentration limit, what product type restrictions, and what warnings are required.
The current database holds 6,300+ ingredient-regulation links across 4,000+ regulations and 30,000+ ingredients, spanning 40+ jurisdictions. These links are the foundation of Layer 1 — every deterministic check is a traversal of these pre-computed relationships. Because jurisdictions are stored hierarchically, a lookup against the US market pulls in federal FDA rules alongside 26 US state laws, Prop 65 warnings, and MoCRA requirements in a single query.
Ingredient Matching
When a user uploads a product file — a PDF label, a spreadsheet, or even a photo of a product box — Navi's AI parser extracts ingredient names from the document. But extracted names are noisy: OCR errors, abbreviations, regional spelling differences, and formatting artifacts.
We need to match these noisy strings to canonical INCI names in our master database. Getting this wrong means either missing a restricted ingredient (false negative) or flagging a safe ingredient as banned (false positive). Both are unacceptable.
Multi-threshold fuzzy matching
We use rapidfuzz.fuzz.token_sort_ratio — a token-aware fuzzy matching algorithm that normalizes word order before comparing. This handles cases like "Sodium Lauryl Sulfate" vs "Sulfate, Sodium Lauryl" that would confuse a naive edit-distance approach.
We use three confidence thresholds:
High-confidence match. The extracted name maps directly to a canonical INCI name. The user sees the match but doesn't need to confirm it.
Possible match. The UI shows "did you mean?" candidates with swap/merge options. The user confirms or rejects. Even confident fuzzy matches include candidates so the user can override.
No match found. A new ingredient record is created with review_status='draft' and source='ai_parse'. The SKU can proceed, but admin review is required before the ingredient is trusted in compliance checks.
Every response entry carries a candidates list so the UI can offer swaps even on confident matches. We found that showing alternatives — even when the top match is strong — catches the 2-3% of cases where token_sort_ratio picks the wrong canonical name from a set of similar INCI names.
MCP Protocol
Inlet exposes a Model Context Protocol (MCP) server that allows any MCP-compatible AI agent to invoke compliance tools programmatically. This is how Navi integrates into external workflows — a product development chatbot, an ERP system's AI assistant, or a batch automation pipeline can all run compliance checks without going through the web UI.
Three execution modes
Call one tool at a time. Example: run a compliance check for SKU X against the EU market.
Run multiple tools in one request. Example: check 50 SKUs against US, EU, and ASEAN in a single call.
Stream results for long-running operations. Useful for bulk compliance checks across large portfolios.
Available tools include compliance checks, ingredient search, regulation lookup, SKU management, and report generation — essentially the full 194-endpoint API surface exposed as MCP tool definitions. The MCP server handles authentication via API keys (SHA-256 hashed, ink_live_ prefix) with the same tenant isolation as the REST API.
Expert-in-the-Loop
Every piece of data that enters Navi's regulatory database goes through human review. We have invested heavily in building tooling that maximizes expert leverage — making it fast and easy for a domain expert to review, approve, or correct large volumes of regulatory data.
Review workflow
All data enters the system as "draft" status — whether it comes from our regulatory agents, the AI parser, or manual entry. Draft data is invisible to customers. An admin must transition it through the review lifecycle: draft → in_review → approved (or rejected).
We built the admin review interface around bulk operations. An admin can:
- Bulk approve by jurisdiction — one click to approve all 802 EU regulations
- Bulk approve by category — approve all cosmetic bans without touching food regulations
- Filter by AI confidence — review low-confidence scrapes first
- Individual review with inline notes, source links, and status transitions
The feedback loop is critical. When a customer reports an issue — a concentration limit that changed, a new ingredient that was recently banned — it flows through our support ticket system to the admin team. The correction is applied, the regulation is re-approved, and the update is immediately reflected in all future compliance checks.
Results
Navi currently processes compliance checks for products with up to 35+ ingredients against markets with 700+ regulations. Here's where we stand:
The 3-layer pyramid design has proven effective. Layer 1 handles the vast majority of checks with perfect confidence — a banned ingredient fails, a permitted ingredient passes. Layer 2 catches the context-dependent edge cases. And Layer 3 provides coverage for the genuinely ambiguous questions that would otherwise require a phone call to a consultant.
The combination of high accuracy on deterministic checks and transparent confidence scoring on AI checks has unlocked our ability to support new markets quickly. Adding a new jurisdiction means loading its regulatory data, linking ingredients to regulations, and running the review workflow. The engine itself doesn't need to change.
What's Next
Navi today handles the deterministic and conditional layers with high accuracy, and the AI layer is functional but early. Our roadmap focuses on three areas:
Continuous source monitoring
We're evolving our 7 regulatory agents from periodic batch runs into always-on watchers that detect regulation changes in near-real-time. When the FDA updates a concentration limit or the EU adds an ingredient to Annex II, Navi should know within hours — not weeks.
Hybrid retrieval for AI reasoning
Layer 3 currently uses direct database lookups to assemble context. We're building a hybrid retrieval system that combines dense vector embeddings (semantic understanding of regulatory intent) with sparse vector embeddings (exact regulatory vocabulary and citation matching). Better retrieval means better AI reasoning.
Fine-tuned reasoning models
As our expert review workflow generates more correction data, we'll train domain-specific reasoning models rather than relying on general-purpose Claude prompts. The goal: 90%+ accuracy on AI determinations with median review times under 10 seconds.
The vision is a compliance engine where the cost of checking any product against any market approaches zero. Not just for cosmetics — for food & beverage, supplements, medical devices, and any category where regulatory complexity is a barrier to global expansion.
We're building the regulatory infrastructure that makes the world one market.