Semantic correction of the knowledge base BEFORE the empirical loop (#59) is built — otherwise the
Observation Store would learn from already-misclassified signals. The Silent Pass conflated two kinds of
signal into one: an OBSERVATION ("I saw an SBOM in the repo") and a REQUIREMENT ("a tender DEMANDS an
SBOM"). They were aliased to the same canonical id, so a tender clause read as "SBOM already present" and
suppressed the very question that should have been asked.
Fix — make the kind explicit and authoritative (no new architecture, data + thin wiring):
- `kind` ∈ {observation, requirement} on ProducedSignal (producer may declare) and on the canonical
SignalVocabularyEntry (AUTHORITATIVE — a mislabelled producer cannot collapse the two).
- Vocabulary split: sbom_file_found → sbom_present (obs) + sbom_required (req);
security_txt_or_cvd_policy → cvd_policy_present (obs) + psirt_required (req); add signed_updates_required.
requirement signals are intentionally UNMAPPED in intake_signal_map (they describe a target, not state).
- silent_intake() consumes ONLY kind==observation; requirement signals are preserved in
`requirements_seen` (visible/auditable) but NEVER become a detected capability.
- normalize_signals() stamps the vocabulary's kind onto every IntakeSignal; unknown ids still pass through.
This is the same Observation-vs-Requirement split the Requirements Verification Platform rests on:
observations are reality, requirements are targets, and their comparison is the delta. A tender / OEM spec /
law now produces requirement signals; scanners / repos / documents produce observation signals.
Tests: rewrote the two test_signal_producer cases that previously ASSERTED the bug (tender == repo) to pin
the correct split; regression — `requires_sbom` yields no capability + stays in requirements_seen while
`cyclonedx_found` still detects sbom_creation; endpoint-level regression that a tender requirement does not
auto-detect and the gap stays asked; vocabulary-kind-overrides-mislabelled-producer. 25 onboarding tests
pass, mypy --strict clean, demo runs, check-loc 0. Runtime effect → deploy + smoke. (Fix A; partial-vs-
detected decoupling follows as Fix B before #59.)
Not the endpoint yet — the bigger knowledge lever first. The Advisor can say "I need 5 answers" but
does not yet decide what it can find out by ITSELF. The Silent Knowledge Pass runs in front of the
Advisor and, from signals existing scanners/parsers already produce (website, repository, documents,
product data), deterministically derives capabilities the company demonstrably HAS + product facts
that drive scope — so every recognised item shrinks the delta and removes a question.
compliance/onboarding/silent_intake.py: silent_intake(signals, signal_map) -> detected_capabilities
(+ evidence already in hand) + product_facts. The signal->conclusion map is curated DATA
(knowledge/onboarding/intake_signal_map.yaml), signals are injected (scanners are upstream). Pure,
deterministic, no LLM. advisor_start gains detected_capabilities (folded into the profile at HIGH
confidence -> covered, not asked) and an auto_detected result + headline.
The experience flips from a question wall to "we already recognised 4 capabilities, 2 product facts
and have 4 pieces of evidence in hand — only these few remain". Order now: Silent Pass -> #58
endpoint/frontend -> #59 empirical loop. NOT new architecture, just an orchestration step in front.
Non-runtime (no app caller) -> no deploy. 15 onboarding tests pass, mypy --strict clean, check-loc 0.
Benjamin Admin