💡
The Opportunity
Why ABI product data and compliance answers are a natural pairing
ABI Makes Products. The Hub Answers Compliance Questions.
ABI Interiors manufactures architectural products — tapware, showers, wastes, grab rails, tiles, accessories.
The Compliance Hub answers questions about Australian and NZ building standards (AS/NZS, NCC, WaterMark, WELS).
These two worlds naturally overlap. A builder asking "what tapware is required for a commercial bathroom?" is also implicitly asking: "what ABI products meet that requirement?"
These two worlds naturally overlap. A builder asking "what tapware is required for a commercial bathroom?" is also implicitly asking: "what ABI products meet that requirement?"
Current Gap
Today, the Hub can tell you exactly what AS/NZS 3718 requires for basin tapware in a commercial bathroom.
It can cite the WaterMark requirement, the WELS rating, operating pressure specs.
What it cannot do: map those requirements to a specific ABI product. The user has to do that manually — cross-referencing spec sheets, checking WaterMark licence numbers, verifying WELS ratings.
What it cannot do: map those requirements to a specific ABI product. The user has to do that manually — cross-referencing spec sheets, checking WaterMark licence numbers, verifying WELS ratings.
Example Queries This Would Enable
User asks
"Does the Elysian basin mixer comply with WaterMark requirements?"
→
Hub answers (today — impossible)
Can answer the standard (AS/NZS 3718 cl. 4.2), but cannot confirm whether ABI's specific product meets it. User must check manually.
→
Hub answers (with module)
Compliance answer + ABI Product Panel: Elysian Basin Mixer — WaterMark WMKA05463 ✓, WELS ★★★★★ (5.0 L/min). Compliant.
User asks
"What tapware meets AS 1428.1 for an accessible bathroom?"
→
Hub answers (today)
Full compliance answer: lever-type controls, reach range 450–1200mm, operating force ≤20N. Product mapping: none.
→
Hub answers (with module)
Same compliance answer + ABI accessible range products (lever-style, DDA-compliant) surfaced as supplementary context.
⚠️
The Risk
What goes wrong if this is done badly — and why architecture matters
The opportunity is real. But the risks are equally real if product data is introduced without strict architectural separation.
Here's what we're protecting against.
🧪 Contamination Risk
High if done wrong
If product data is mixed into the compliance corpus embeddings, marketing language pollutes the vector space.
Compliance queries start returning product sheets alongside clauses.
❌ What happens if product data is mixed in
Q: "What are the waterproofing requirements under AS 3740?"
A: "Waterproofing membranes must extend… ABI WaterSeal Pro provides industry-leading waterproofing with FlexShield™ technology…"
A: "Waterproofing membranes must extend… ABI WaterSeal Pro provides industry-leading waterproofing with FlexShield™ technology…"
✅ Under the recommended architecture
Q: "What are the waterproofing requirements under AS 3740?"
A: AS 3740 cl. 3.4: membrane must extend 75mm… [citation]. Product data never enters this prompt.
A: AS 3740 cl. 3.4: membrane must extend 75mm… [citation]. Product data never enters this prompt.
🏛️ Trust Risk
High if done wrong
The Hub's credibility depends on being a neutral, authoritative compliance reference.
If users suspect product recommendations are baked into compliance answers, the tool's authority collapses.
❌ Trust-destroying pattern
Compliance answer that naturally gravitates toward ABI products because they're in the same embedding space.
No explicit recommendation, just subtle semantic bias. Worse than explicit — it's invisible.
✅ Trust-preserving pattern
Compliance answer from standards corpus only.
Separate panel, clearly labelled "🏭 ABI Product Context".
Explicit disclaimer: "Separate from regulatory requirements."
Separate panel, clearly labelled "🏭 ABI Product Context".
Explicit disclaimer: "Separate from regulatory requirements."
📊 Accuracy Risk
Manageable
Product specs change. New versions, discontinued lines, updated certifications, changed WELS ratings.
Stale product data in the corpus = wrong answers with high confidence.
❌ Without refresh controls
Hub says "ABI Elysian Mixer — WaterMark certified."
Certification lapsed 3 months ago. Product discontinued.
Builder relies on it. Compliance issue on-site.
Certification lapsed 3 months ago. Product discontinued.
Builder relies on it. Compliance issue on-site.
✅ Mitigation plan
Quarterly refresh cycle + automated checks against ABCB WaterMark register and WELS database.
"Last updated" timestamp shown per product card.
📈 Scope Creep Risk
Real but containable
Once product data is in the system, pressure builds to expand: competitor products, pricing, availability,
distributor stock levels. Each addition adds complexity and potential for bias.
❌ Slippery slope
Month 1: ABI tapware. Month 3: "Can we add competitors?" Month 6: "Can we include pricing?" Month 9: "What about availability by state?"
The Hub is now a product catalogue with compliance as an afterthought.
✅ Hard boundary
Product module = ABI products only, compliance-mapped specs only.
No pricing. No availability. No competitors.
Decisions about scope expansion require explicit Grant sign-off.
No pricing. No availability. No competitors.
Decisions about scope expansion require explicit Grant sign-off.
🛡️
Bottom Line on Risk
All four risks are real, but all four are zero under the recommended architecture.
The compliance RAG pipeline is literally unchanged — it never sees product data.
Product results are generated in a parallel query against a separate index and rendered as a downstream UI layer.
Industry precedent (UpCodes, NatSpec) confirms this is the correct pattern.
🏗️
Architecture Options
Three paths forward — click each to expand the full analysis
A
Option A — Park It
Finish the phase plan first. Revisit when all blocks are done.
Do nothing now. Complete Block C (Checklist v2), Block D (testing), Block E (decisions),
and all remaining phase milestones. After the full phase plan is complete, revisit whether
an ABI product module makes sense as a Phase 3 feature.
✅ Pros
- Zero risk to compliance corpus quality — nothing changes
- Zero distraction from the current phase plan
- Decision can be made with more information after Phase 2 is live
- Product data strategy becomes clearer once real users are using the Hub
❌ Cons
- Missed opportunity — every query run without product mapping is a lost touchpoint
- Retrofitting product data after Phase 2 is live is harder than designing it in now
- The team has to manually cross-reference ABI products for every compliance answer
- No signal on whether the use case is as valuable as it looks in theory
B
Option B — Green-Light Design
Recommended
Hybrid supplementary context — isolated product module, compliance corpus untouched.
Spec and begin building a physically isolated product module in the next run. Product data lives in its own
D1 table + separate Vectorize index — never co-indexed with compliance embeddings. Product results are generated
in a parallel query and surfaced as a clearly-labelled supplementary panel after the compliance answer.
🔒 Separate Data Plane
Product embeddings in
abi-products-index. Compliance retrieval queries only standards-embeddings. Never cross-contaminated.⚡ Parallel, Post-Hoc
Compliance answer generated first — unmodified. Product search runs in parallel, results added as UI layer. Never inside Claude's compliance context window.
👁️ Visually Distinct
Product panel uses different border colour (teal vs indigo), explicit "🏭 ABI Product Context" header, and disclaimer. Users cannot confuse it with compliance citations.
✅ Pros
- Gets the architecture right early — retrofitting is always harder
- Zero contamination risk under this architecture (verified by design)
- UpCodes and NatSpec both use this exact pattern successfully
- Tapware-first scope is low risk, high value, and naturally bounded
- Reversible — remove the product index + UI component and compliance is unchanged
- Enables benchmark CI gate: auto-verify ≤1% regression on every product data update
❌ Cons
- Design effort costs a session (~1 run to spec the architecture)
- ~60–95 hours total build time across 3–4 weeks
- Requires structured ABI product data (CSV/database export vs. manual entry)
- Needs quarterly maintenance refresh cycle (automation helps but adds complexity)
Implementation Phasing
Phase 0 · 1 day
Grant Decision
Scope, data source, audience confirmed
Phase 1 · Weeks 1–2
Data Infrastructure
D1 table + Vectorize index + tapware ingestion
Phase 2 · Weeks 2–3
Parallel Search
Product query wired into handler + SSE extension
Phase 3–4 · Week 3–4
UI + Validation
Product cards + benchmark gate + feature flag deploy
C
Option C — Kill It
Not worth the risk. Keep the Hub as a pure compliance tool.
The Compliance Hub is a compliance tool, not a product catalogue. Adding product data — even in a separate module —
creates a category confusion that undermines the tool's core value proposition. If ABI wants product lookup,
build a separate tool for it. Keep these concerns completely separated.
✅ Pros
- Absolute clarity of purpose — the Hub is a compliance tool, full stop
- Zero scope creep risk, ever
- No product data maintenance burden
- No risk of users confusing product context with compliance requirements, even with labelling
❌ Cons
- Misses the natural synergy — ABI products map to ABI compliance domains
- Users asking "does ABI product X comply?" get "I don't know ABI products" — a dead end
- UpCodes and NatSpec have already proven this combo works at scale
- A separate "product catalogue" tool adds a second tool for users to context-switch between
🖥️
UI Mockup — Option B in Practice
How the hybrid supplementary approach would look to the end user
The key design principle: the compliance answer and the product panel must be visually unmistakable as separate things.
Different colour scheme, different header, explicit disclaimer. A user skimming cannot accidentally read a product spec as a compliance requirement.
What tapware is required for a commercial bathroom under AS/NZS 3718?
Standards Mode
Compliance Answer
From standards corpus · 3 citations
Under AS/NZS 3718:2005, all tapware installed in commercial bathrooms must:
1. WaterMark certification — All tapware must bear the WaterMark conformance mark AS/NZS 3718 cl. 2.1. Tapware without WaterMark certification is not permitted for installation in Australia or New Zealand.
2. Flow rate compliance — For commercial applications, the WELS scheme AS/NZS 6400:2016 mandates a minimum 3-star rating. Basin taps in public facilities must not exceed 9 L/min at 500 kPa.
3. Operating conditions — Tapware must be rated for operating pressures of AS/NZS 3718 cl. 4.2 35–1000 kPa, with temperature ratings to 90°C for hot-water-rated fittings.
1. WaterMark certification — All tapware must bear the WaterMark conformance mark AS/NZS 3718 cl. 2.1. Tapware without WaterMark certification is not permitted for installation in Australia or New Zealand.
2. Flow rate compliance — For commercial applications, the WELS scheme AS/NZS 6400:2016 mandates a minimum 3-star rating. Basin taps in public facilities must not exceed 9 L/min at 500 kPa.
3. Operating conditions — Tapware must be rated for operating pressures of AS/NZS 3718 cl. 4.2 35–1000 kPa, with temperature ratings to 90°C for hot-water-rated fittings.
Supplementary: ABI Product Context
ABI Product Match
2 products found · tapware → AS/NZS 3718
Updated quarterly · Last refresh: 2026-06-01
Elysian Basin Mixer
SKU: ELY-BM-CH · Brushed Chrome
WaterMark
✓ WMKA05463
Standard
AS/NZS 3718:2005
WELS Rating
★★★★★ (5.0 L/min)
WELS Reg. ID
AU-23841
Pressure range
35–800 kPa
Crestline Basin Mixer
SKU: CRS-BM-MB · Matte Black
WaterMark
✓ WMKA04917
Standard
AS/NZS 3718:2005
WELS Rating
★★★★ (6.0 L/min)
WELS Reg. ID
AU-22194
Pressure range
50–1000 kPa
Indigo = Compliance
All compliance citations, headers, and UI chrome use the indigo accent (#6366f1) — the existing Hub design language.
Teal = ABI Products
The product panel exclusively uses teal (#14b8a6). No user can visually confuse it with the compliance section.
Explicit Disclaimer
The disclaimer is non-negotiable — it appears in every product panel, every time. Not a legal footnote, but a visible part of the UI.
⚡
Your Call
Select an option and leave notes — this is the decision gate before any build starts
This decision gates the entire E3 build. Nothing gets built until Grant confirms the direction.
Select your preferred option below and add any conditions, scope changes, or questions for the next run.
A
Park It
Finish Phase 2 first. Block C, Checklist v2, then Block D testing.
Revisit product module after all blocks are done.
↑ Zero risk ·
↓ Lost opportunity
✦ Recommended
B
Green-Light Design
Spec the isolated product module architecture in the next run.
Tapware-first. Separate index. Build incrementally after Phase 2.
↑ Zero contamination risk · Best timing ·
~ 60–95 hrs build
C
Kill It
The Hub is a compliance tool only. If product lookup is needed,
build a separate tool entirely. No product data, ever.
↑ Maximum purity ·
↓ No product synergy
Notes / Conditions / Questions
🎯
Scoping Decisions — Pick Your Path
Each question has ranked options with a recommendation. Click to select — selections are included in the Copy Summary.
Q1
Scope — What product categories to include at launch?
Q2
Data source — Where does product data come from?
Q3
Audience — Who sees product results?
Q4
Product data ownership — Who keeps it current?
Q5
Revenue model — Design for external manufacturer participation?
Q6
Automated verification — Build quarterly register checks?
📋 Decision Summary
Selected
No option selected yet
Ranking
No ranking set yet
Notes
No notes added yet
Scoping
No scoping decisions made yet