Step 12: Confirm List [CONFIRM WITH DEVELOPER]

This document compiles every architectural assumption, rationale, and configuration decision that cannot be proven definitively from code inspection alone, providing the developer with an actionable checklist to verify before technical interviews.

Technical & Architectural Decisions to Confirm

#	Topic	Documentation Rationale	Code Evidence	Developer Action
1	Air-Gapped Local Embeddings vs OpenAI	Assumed chosen to ensure 100% data confidentiality for unreleased industrial hardware, eliminate recurring token fees, and allow deployment in offline manufacturing plants.	[`app.py:L24`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/app.py#L24) uses `TextEmbedding` (`BAAI/bge-small-en-v1.5`) via FastEmbed ONNX with no cloud API keys.	Confirm if enterprise client privacy or offline deployment was the primary driver.
2	FAISS `IndexFlatIP` Exact Search vs HNSW	Assumed chosen because the corpus is compact ($N=47$) and regulatory compliance demands 100% exact recall rather than probabilistic approximation.	[`rebuild_faiss_index.py:L20`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/rebuild_faiss_index.py#L20) uses `IndexFlatIP`.	Confirm if exact recall was the determining factor.
3	Dense Similarity Threshold (0.45)	Assumed chosen through empirical regression testing on `eval_guardrail.py` to balance catching technical phrasing while rejecting out-of-domain commercial noise.	[`guardrail.py:L38`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/guardrail.py#L38) sets `similarity_score >= 0.45`.	Confirm if 0.45 was calibrated against specific edge cases.
4	Checklist Weights in Gap Engine	Assumed the weighting distribution (e.g., 25% for test benches, 15% for NABL calibration) mirrors official BIS Scheme-I inspection scoring guidelines.	[`gap_engine.py:L4-L19`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/gap_engine.py#L4-L19) assigns specific weights totaling 100%.	Confirm if weights were derived from official BIS auditor manuals or domain consultant feedback.
5	React 19 SPA vs Next.js SSR	Assumed chosen because the platform is an internal enterprise audit dashboard that does not require public search engine indexing, making Next.js SSR unnecessary.	[`bis-frontend/package.json`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/bis-frontend/package.json) uses Vite 8 + React 19.	Confirm if bundle simplicity was the main rationale.
6	Top-1 Nearest Neighbor ($k=1$)	Assumed chosen to provide a concise, unambiguous statutory audit pack for standard queries, leaving multi-standard aggregation for future milestones.	[`app.py:L90`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/app.py#L90) sets `k=1`.	Confirm if single-standard focus was intentional for the demo MVP.
7	In-Memory JSON Corpus vs SQLite/Postgres	Assumed chosen for maximum portability and zero-configuration Docker deployments without needing database migrations.	[`app.py:L28-L29`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/app.py#L28-L29) loads `model2_corpus.json` into RAM.	Confirm if avoiding database operational overhead was the objective.
8	Inline Vanilla Styles vs Tailwind CSS	Assumed chosen to keep all component styles completely self-contained in `App.jsx` without external build-step dependencies.	[`bis-frontend/src/App.jsx`](file:///Users/avishjain/avishjain9-repos/21-bis-compliance-engine/bis-frontend/src/App.jsx) uses native inline style objects.	Confirm if self-contained code was the preference.