# Architecture de Labfy Investigation Le parcours local `CURRENT` de jobs persistants et de reprise est détaillé dans [LOCAL_JOBS_RECOVERY.md](architecture/LOCAL_JOBS_RECOVERY.md). Son JobStore opérationnel séparé ne remplace pas la base métier V20 et ne modifie pas V21. Le contrôle navigateur local sur espace exclusivement synthétique est décrit dans [WEB_WORKSPACE_CONTROL.md](architecture/WEB_WORKSPACE_CONTROL.md). Cette surface mutationnelle J6 est distincte des démonstrations read-only J2–J5. La [recherche OSINT assistée V1](architecture/OSINT_ASSISTED_RESEARCH.md) est `CURRENT` dans le worktree uniquement pour son parcours de laboratoire : le JobStore V4 est additif à V3, les grants sont explicites et aucun fournisseur public n'est configuré ou qualifié. Elle ne modifie ni V20 ni V21. Les fondations locales de l'[agent opérationnel](architecture/OPERATIONAL_AGENT.md), de l'[exécution sandboxée](architecture/SANDBOX_TOOL_EXECUTION.md) et de l'[egress privacy](architecture/PRIVACY_EGRESS.md) restent strictement séparées de la Policy et du JobStore. Le chemin rootless live `PRIVACY_TOR` et la capability Internet passive sont `CURRENT local` après un smoke Qwen unifié `PASS_LOCAL_SPECIMEN`, sans repli direct. Le [provisionnement contrôlé](architecture/TOOL_PROVISIONING.md), les [générations rootless](architecture/TOOLBOX_GENERATIONS.md), les [manifestes de capability](architecture/CAPABILITY_MANIFESTS.md) et la [self integration](architecture/QWEN_SELF_INTEGRATION.md) sont `CURRENT local` sur `SPECIMEN`. Les décisions humaines A/B/C1/C2 restent hors du langage modèle. L'Agent Gateway orchestre ; Policy et services réévaluent chaque exécution. Le worktree de développement est séparé de la toolbox d'exécution. > **Statut :** direction canonique v0.1.0 > **Dernière mise à jour :** 2026-09-27 > **Portée :** architecture actuelle et cible Labfy V2 > **Interface CURRENT :** le Web local est l'unique interface utilisateur ; > GTK et ses tests/widgets de renderer sont retirés. Le cœur C17, SQLite, les > services, capabilities et JobStore V4 n'en dépendent pas. ## 1. Objet et niveaux de maturité Labfy Investigation est un environnement local-first d'investigation numérique centré sur un graphe interactif. Chaque élément pertinent doit pouvoir devenir un pivot vers une capacité applicable, sans perdre sa provenance. Ce document distingue explicitement : - **CURRENT** : comportement présent dans le code et les migrations ; - **TARGET** : contrat architectural v0.1.0 à implémenter progressivement ; - **UNDECIDED** : décision réservée à une tranche architecturale ultérieure. Une description `TARGET` ne prouve pas qu'une fonctionnalité est disponible. Pour l'état courant, le code, les tests et les migrations priment. Les contrats spécialisés complètent ce document sans le remplacer : - [graphe d'investigation](architecture/INVESTIGATION_GRAPH.md) ; - [Toolkit et adapters](osint/TOOLKIT.md) ; - [sécurité, scope et secrets](security/SECURITY_MODEL.md) ; - [design system](ui/DESIGN_SYSTEM.md) ; - [décisions architecturales](architecture/decisions/0001-web-local-first.md). ## 2. Principes non négociables ### 2.1 The graph is the investigation Le graphe devient la représentation principale de l'enquête. Il ne constitue ni une base indépendante ni une copie appauvrie de SQLite : il projette le réseau logique des objets métier et de leurs liens. Les objets projetables incluent notamment : ```text PERSON ORGANIZATION COMPANY EMAIL PHONE USERNAME ALIAS ACCOUNT SOCIAL_PROFILE DOMAIN HOSTNAME IP_ADDRESS URL CERTIFICATE ADDRESS LOCATION BANK_ACCOUNT IBAN BIC TRANSACTION CRYPTO_WALLET CRYPTO_TRANSACTION DOCUMENT IMAGE VIDEO FILE DEVICE EVENT EVIDENCE SOURCE OBSERVATION CLAIM HYPOTHESIS ``` Cette projection unifiée ne transforme pas tous ces objets en lignes de `entites`. Le modèle conserve des catégories distinctes : - entités et identifiants pivotables ; - artefacts et preuves ; - sources et exécutions ; - observations et claims ; - événements et transactions ; - hypothèses et décisions humaines. ### 2.2 Une enquête, plusieurs projections ```text INVESTIGATION GRAPH │ ┌────────────────┼────────────────┐ │ │ │ Identity Infrastructure Finance │ │ │ Timeline Geo Evidence ``` Identity, Infrastructure, Finance, Timeline, Geo et Evidence sont des vues du même réseau logique. Elles partagent identités, relations, provenance et règles d'accès. Elles ne possèdent pas leur propre vérité métier. ### 2.3 Local-first Par défaut : - SQLite reste local ; - les artefacts et preuves restent locaux ; - le graphe et les services principaux s'exécutent localement ; - aucune dépendance à un cloud Labfy n'est requise ; - un accès réseau existe seulement lorsqu'une capacité le demande. Une interface Web locale ne modifie pas ce contrat. La surface HTTP future doit écouter localement par défaut, appliquer une authentification adaptée à sa surface réelle et ne jamais exposer silencieusement une enquête sur le réseau. ### 2.4 Preuves originales immuables Une preuve originale importée n'est jamais modifiée. Toute conversion, annotation, extraction, transcription, analyse ou expurgation produit un objet dérivé, lié à son entrée et accompagné d'une empreinte. ### 2.5 Provenance avant automatisation Une automatisation ne peut être activée avant de pouvoir répondre à : ```text WHAT? WHERE FROM? WHEN? HOW? WHICH TOOL? WHICH VERSION? WHICH QUERY? WHICH PARAMETERS? WHAT RAW RESULT? WHAT NORMALIZED RESULT? WHAT TRANSFORMATION? WHAT HASH? WHAT CONFIDENCE? WHO CONFIRMED IT? ``` ### 2.6 Une hypothèse n'est pas un fait Une similarité, une corrélation ou un identifiant commun produit un signal ou une hypothèse. Il ne devient pas silencieusement une identité confirmée. ## 3. Architecture actuelle — CURRENT Le produit actuel est principalement écrit en C17 avec GLib/GIO et SQLite. ```text Web frontend local │ intentions et affichage Application / services / tasks │ orchestration Models / DAO / Database │ SQLite Evidence files ── controlled services ── derived artifacts External tools ── GSubprocess ────────── raw/normalized results ``` Contrats actuels à préserver : - aucun accès SQLite direct depuis les widgets ; - aucun GTK dans les modèles, DAO ou services métier ; - transactions pour les opérations composées ; - migrations compatibles avec les anciennes bases ; - ownership explicite des allocations ; - outils lancés avec des arguments séparés, jamais via un shell construit ; - opérations longues hors du thread principal ; - données de test exclusivement synthétiques. Le socle comprend déjà : - enquêtes autonomes et base versionnée ; - preuves, extractions, entités et relations ; - graphe Web interactif et positions persistantes ; - tâches asynchrones en mémoire ; - registre initial d'outils ; - premiers parcours DNS et documentaires ; - provenance partielle des exécutions OSINT ; - observations brutes, normalisées et corrigées dans certains domaines ; - décisions humaines append-only pour les parcours d'identité. - projection J3 expérimentale indépendante de GTK, lisant une base V20 en read-only effectif et publiant un snapshot v2 pour le prototype Web ; cette capacité est documentée dans [CORE_GRAPH_READONLY.md](architecture/CORE_GRAPH_READONLY.md). - service J3 ciblé d'analyse EML native : original contrôlé, dérivé versionné, extraction et observations `proposed` sont publiés atomiquement en V20, puis projetés en snapshot v3 sans reconstruction dans le pont Web ; voir [EML_ANALYSIS_TO_GRAPH.md](architecture/EML_ANALYSIS_TO_GRAPH.md). - poste Web local contrôlé : une instance loopback possède une bibliothèque explicitement choisie et ne rend active qu'une enquête à la fois. Le bridge C reste le créateur des enquêtes, le lecteur des projections et l'unique accès aux stockages métier ; voir [WEB_WORKSPACE_CONTROL.md](architecture/WEB_WORKSPACE_CONTROL.md). Ces composants doivent être réutilisés ou migrés. La direction V2 n'autorise pas une réécriture générale du cœur fonctionnel. ## 4. Architecture cible — TARGET ```text ┌───────────────────────────────────────────────┐ │ WEB FRONTEND │ │ │ │ INVESTIGATION GRAPH — MAIN UI │ │ │ │ Dashboard / Graph / Timeline / Evidence │ │ Finance / Infrastructure / Geo / Reports │ └──────────────────────┬────────────────────────┘ │ HTTP API / EVENTS │ ┌──────────────────────▼────────────────────────┐ │ LABFY CORE │ │ │ │ Evidence / Provenance │ │ Entity & Observation Model │ │ Adapter Registry │ │ Job Engine │ │ Pivot Engine │ │ Correlation Engine │ │ Investigation Planner │ │ Scope / Policy │ └──────────────────────┬────────────────────────┘ │ SQLite ``` L'interface principale actuelle est Web. GTK est supprimé ; temporaire et ne sera pas supprimé avant qu'un remplacement validé couvre les parcours nécessaires. Restent volontairement `UNDECIDED` : - framework frontend ; - JavaScript ou TypeScript exact ; - serveur HTTP local ; - format détaillé de l'API ; - Server-Sent Events, WebSocket, polling ou combinaison ; - stratégie de packaging du frontend. Le choix JavaScript natif + SVG + serveur Python stdlib + SSE est `CURRENT` uniquement pour le prototype J2. Le mode J3 cœur réutilise cette surface sans accès SQLite côté Python. Le protocole d’outils agent V1 emploie exclusivement un polling HTTP borné, sans SSE opérationnel. Le runtime de modèle local V1, également à polling borné et sans SQLite Python, est `CURRENT local` après validation fake loopback ; voir [AGENT_TOOL_PROTOCOL.md](architecture/AGENT_TOOL_PROTOCOL.md) et [LOCAL_MODEL_AGENT_RUNTIME.md](architecture/LOCAL_MODEL_AGENT_RUNTIME.md). Ces choix expérimentaux ne décident pas le serveur, le renderer ou le packaging de production. Le moteur graphique et la bibliothèque HTTP restent également `UNDECIDED`. Aucune dépendance Node, npm ou frontend n'est introduite par la tranche fondation. ## 5. Socle polyglotte C17 reste privilégié pour : - modèles et services métier existants ; - SQLite, migrations et transactions ; - provenance et intégrité des données ; - orchestration principale ; - API locale si l'étude dédiée le confirme ; - chemins sensibles aux performances et à la mémoire. Labfy V2 peut aussi utiliser : ```text Python adapters ou outils matures JavaScript/TypeScript frontend Web SQL persistance et requêtes controlled shell scripts maintenus, sans entrée concaténée external CLI tools capacités spécialisées isolées HTTP APIs services publics ou autorisés ``` Un composant externe mature est préférable à une réimplémentation médiocre si sa licence, sa maintenance, ses limites, son isolation, sa normalisation et sa provenance sont maîtrisées. ## 6. Modèle de connaissance ### 6.1 Objets métier Une entité possède une identité durable et peut servir de pivot. Un artefact est un fichier ou résultat matériel. Une observation décrit ce qu'une source a fourni. Un claim exprime une affirmation structurée. Une hypothèse relie des signaux qui nécessitent une validation. Un événement ou une transaction porte une sémantique temporelle propre. Les nouveaux types simples doivent être ajoutés par un registre descriptif et des canonicalizers, sans multiplier les branchements UI. Une table spécialisée est réservée aux domaines qui possèdent de vraies contraintes structurelles. ### 6.2 Nature, revue et hypothèses Trois dimensions restent orthogonales : ```text information_nature: OBSERVED | DECLARED | DERIVED | CORRELATED | INFERRED review_state: UNREVIEWED | CONFIRMED | CONTRADICTED | REJECTED hypothesis_state: PROPOSED | UNDER_REVIEW | SUPPORTED | CONTRADICTED | CONFIRMED | REJECTED ``` `HYPOTHESIS` est un objet, pas une nature d'observation. ### 6.3 Confiance explicable La direction canonique est : ```text UNKNOWN | LOW | MODERATE | HIGH ``` Chaque niveau doit être accompagné de raisons, facteurs contradictoires, nombre de sources indépendantes et origine humaine ou automatique. Les scores historiques peuvent être conservés pour compatibilité, sans être réinterprétés silencieusement. ## 7. Graphe et espace de travail ### 7.1 Compression sémantique Le graphe cible doit rester utilisable avec des milliers d'objets : - semantic clustering ; - collapse/expand ; - niveaux de détail ; - filtrage par type, temps, relation, source, état et confiance ; - isolation d'un chemin ; - focus mode ; - agrégats visuels réversibles. Une agrégation masque ou résume. Elle ne supprime ni ne fusionne les objets métier sous-jacents. ### 7.2 Focus Workspace La sélection d'un objet doit pouvoir : - recentrer le graphe ; - isoler le voisinage pertinent ; - présenter relations et chemins ; - afficher observations, preuves et sources ; - afficher timeline et hypothèses ; - demander les actions et pivots applicables ; - revenir immédiatement au graphe global. Le novice voit des actions métier, par exemple « Analyser le domaine ». L'expert peut descendre jusqu'aux versions, paramètres, sorties et transformations. ## 8. Toolkit Registry et adapters Le frontend consomme des capabilities et ne connaît pas les commandes internes des outils. Une déclaration de capacité contient conceptuellement : ```text tool_id adapter_id capability_id accepted_object_types produced_object_types action_class effects requirements network_required credentials_required cost risk availability health tool_version adapter_version ``` Familles d'adapters prévues : - native adapter ; - subprocess adapter ; - HTTP API adapter ; - manual adapter. Un adapter ne dépend ni de GTK ni de SQLite. Il exécute ou collecte, conserve un résultat brut, puis produit des observations normalisées. Les services du cœur contrôlent persistance, jobs, provenance, ressources et scope. Le premier groupe de candidats comprend ExifTool, Tesseract, qpdf, RDAP, Certificate Transparency, Wayback, Subfinder, theHarvester et Maigret. Leur présence dans la roadmap ne signifie pas qu'ils sont actuellement intégrés. ## 9. Provenance La navigation « Why do we know this? » suit : ```text ENTITY / CLAIM ↑ OBSERVATION ↑ TRANSFORMATION ↑ NORMALIZED RESULT ↑ EXECUTION ATTEMPT ↑ RAW ARTIFACT / SOURCE ↑ REQUEST + TOOL + ADAPTER + SCOPE ``` La cible conserve : - opération logique et tentatives ; - outil, adapter et versions ; - requête, paramètres expurgés et cible ; - début, fin, statut et erreur ; - stdout, stderr et réponses brutes bornées ; - artefacts, tailles, rôles, types MIME et SHA-256 ; - observations normalisées ; - transformations et règles versionnées ; - décisions humaines ; - snapshot du scope et de la politique. Les logs texte ne remplacent pas ce modèle. ## 10. Job Engine et isolation Le moteur persistant cible connaît : ```text QUEUED | RUNNING | WAITING | RATE_LIMITED | COMPLETED | PARTIAL | FAILED | CANCELLED ``` Il gère dépendances, priorité, progression, timeout, retry, backoff, cancellation, concurrence, idempotence et récupération après crash. L'exécution d'un outil externe doit prévoir : - argv séparé, sans shell concaténé ; - environnement minimal ; - répertoire de travail isolé ; - capture en streaming avec plafonds ; - timeout et cancellation ; - groupe de processus et arrêt des descendants ; - limites CPU, mémoire, fichiers et descripteurs ; - artefacts atomiques et empreintes ; - publication idempotente. Le statut `PARTIAL`, l'aperçu tronqué et l'artefact complet réellement conservé restent distincts. Une empreinte ne décrit jamais implicitement des octets qui n'ont pas été conservés. Une opération logique, sa tentative physique et la publication de ses résultats portent des identités séparées ; une clé d'idempotence ne garantit pas une exécution réseau exactement une fois. ## 11. Pivots, budgets et planner ### 11.1 Pivots contextuels ```text OBJECT ↓ CAPABILITY DISCOVERY ↓ PIVOT CANDIDATE ↓ JOB / ADAPTER ↓ OBSERVATIONS ↓ NEW OBJECTS / NEW PIVOTS ``` Le moteur contrôle déduplication, cache, profondeur, cycles, dépendances, priorité, coût, risque et rate limits. ### 11.2 Pivot budget Le budget est multidimensionnel : ```text max_depth max_pivots max_network_requests max_wall_time max_bytes max_external_cost max_risk ``` Une action `INVESTIGATE` ne signifie jamais « tout exécuter sans limite ». ### 11.3 Investigation Planner Le planner répond : ```text Given everything currently known, what should we investigate next? ``` Sa première version doit être déterministe et explicable. Elle considère les capacités, exécutions passées, dépendances, coût, risque, fiabilité, budget et gain d'information attendu. Chaque classement `HIGH`, `MEDIUM` ou `LOW` est accompagné de raisons. Une IA autonome opaque n'est pas un objectif v0.1.0. ## 12. Autonomie, actions et scope L'autonomie progresse strictement dans cet ordre : ```text MANUAL ASSISTED AUTONOMOUS_PASSIVE AUTONOMOUS_AUTHORIZED ``` La première autonomie réelle visée est `AUTONOMOUS_PASSIVE`, après provenance, jobs persistants, adapters, pivots, budgets, politiques et scope. Les actions sont classées : ```text PASSIVE | PUBLIC_ACTIVE | AUTHORIZED_INTRUSIVE | PROHIBITED ``` Leurs effets sont déclarés séparément : ```text READ_ONLY | STATE_CHANGING | DESTRUCTIVE | PERSISTENCE | CREDENTIAL_ACCESS | DATA_EXTRACTION ``` Chaque tentative doit recevoir une décision `IN_SCOPE`, `OUT_OF_SCOPE` ou `UNKNOWN`. Une cible découverte, un sous-domaine, une IP résolue ou une infrastructure partagée n'hérite jamais automatiquement d'une autorisation intrusive. Le contact réseau `NONE`, `THIRD_PARTY` ou `TARGET` est déclaré séparément de la classe d'action. Une future autorisation référence cibles, actions, période, opérateur et exclusions ; l'interface ne crée jamais à elle seule le droit d'agir. Les capacités intrusives ne font pas partie de v0.1.0. Leur développement exigerait une tranche et une autorisation explicites compatibles avec le cadre légal et le contrat produit. ## 13. Corrélation et similarité Les règles de corrélation doivent être déterministes, documentées, testables, versionnées et rejouables. Chaque résultat conserve ses inputs, normalisations, règle, version et explication. Les égalités exactes et similarités restent séparées : - SHA-256 identique : contenu binaire identique ; - image perceptuellement proche : signal de similarité ; - même username : réutilisation possible ; - même IP : infrastructure partagée possible ; - proximité temporelle : signal contextuel. Aucune de ces observations ne confirme à elle seule une personne ou un opérateur commun. ## 14. UX et design system Le design cible utilise Catppuccin Mocha et Lavender comme accent principal. Les couleurs sont des tokens sémantiques centralisés ; elles ne doivent pas être dupliquées arbitrairement dans les composants. L'UX novice expose des actions métier. L'UX expert rend accessibles : ```text tool / version adapter / version query / parameters execution / stdout / stderr raw artifact / normalized observations transformation / correlation rule / provenance ``` Le mode simplifié masque des détails ; il ne les supprime jamais. ## 15. Ordre de construction L'ordre canonique est défini par [ROADMAP.md](ROADMAP.md). En résumé : 1. J0, fondation documentaire et contrat v0.1.0 ; 2. J1, baseline et stabilisation du travail financier indépendant ; 3. J2, choix Web/graphe/API et prototype synthétique en lecture seule ; 4. J3 à J5, services, provenance, runner, jobs et policies ; 5. J6, vertical Web Graph relié au backend ; 6. J7 et J8, pivots, corrélation, planner et autonomie passive ; 7. J9, projections spécialisées et rapports. Le premier lot J9 CURRENT est défini dans [EVIDENCE_TIMELINE_REPORT.md](architecture/EVIDENCE_TIMELINE_REPORT.md) : trois projections du graphe commun et un dossier de rapport minimisé, atomique et vérifiable, sans évolution de V20, V3 ou V21. J0 s'arrête à la documentation. Aucun choix de stack ou prototype J2 n'est réalisé par cette fondation. ## 16. Incrément local J4 Le lot [Toolkit local et runner borné](architecture/LOCAL_TOOLKIT_RUNNER.md) est `CURRENT` dans le worktree : registre statique réellement consommé, capacité EML native, adapter ExifTool subprocess, runner POSIX borné, publication V20 et projection Web read-only. Il ne transforme pas le prototype en serveur de production et ne livre pas les jobs/policies J5. Les autres runners historiques restent une dette explicitement non couverte. Le parcours `CURRENT` de création d’espace vide et d’import navigateur est défini dans [`LOCAL_WORKSPACE_IMPORT.md`](architecture/LOCAL_WORKSPACE_IMPORT.md). Il conserve V20 et le JobStore V3, et sépare création, réception, publication, analyse approuvée et rapport. ## 17. Espace local, revue et projections — CURRENT expérimental Le parcours local est limité à une instance loopback et à des validations sur fixtures `SPECIMEN`. Son lanceur peut ouvrir une bibliothèque locale explicitement choisie, en créer les enquêtes par le bridge C et n'en active qu'une seule dans une instance. Il ne rouvre pas implicitement l'enquête d'une session précédente. Cette surface ne change pas son statut : le Web reste le parcours fonctionnel actuel et le serveur, son packaging ainsi que le choix du renderer de production restent `UNDECIDED`. Le runtime métier demeure V20 et le JobStore opérationnel demeure V3 ; le poste Web ne migre ni ne modifie la tranche financière V21. L'état d'instance et le secret d'amorçage sont séparés dans le runtime privé XDG (avec un repli privé propre à l'UID lorsque `XDG_RUNTIME_DIR` est absent) ; la configuration durable est placée dans l'état XDG privé. La bibliothèque est une destination locale fournie explicitement au lancement : elle n'est pas déduite d'une dernière enquête ouverte. Après la publication d'une preuve V20, le bridge Web demande au cœur C un aperçu EML, PNG ou JPEG. L'original, son chemin et son répertoire ne sont jamais servis par HTTP. Le cœur vérifie l'intégrité, les bornes et le type effectif, puis retourne seulement une représentation inerte et bornée. L'identité de cache retournée décrit cette représentation ; il n'existe pas de cache disque persistant d'aperçu. Les réponses sont `no-store` et le navigateur ne peut pas choisir un UUID autre que celui de la preuve demandée par l'interface. La revue d'observation est une transaction V20 dont chaque intention porte un UUID d'opération et une révision attendue. Le journal V20 consigne l'opération mais n'est pas signé : il fournit de la traçabilité locale, pas une certification. Confirmer une observation signifie uniquement que sa revue est confirmée ; cela ne confirme jamais une identité. La correction humaine reste une valeur distincte des valeurs brute et normalisée. Un même UUID avec la même intention est rejoué sans doublon ; une intention différente est refusée. La promotion demeure volontaire. Elle peut créer ou rattacher explicitement un indicateur e-mail, domaine ou IP ; le rattachement exige l'UUID d'une entité compatible. Le retrait conserve l'observation et les liens indépendants, et ne supprime pas aveuglément une entité partagée. Les données brutes, UUID d'observation et UUID d'extraction ne sont pas réécrits par ces opérations. Le rejeu idempotent d'une extraction EML existante n'accepte que la revue, la correction, la promotion ou le retrait humains liés à une entrée du journal `observation.review.v1`. Il ne relance pas l'analyse et ne consomme aucun budget. Les champs originels de l'extraction et ses artefacts restent soumis aux contrôles d'immuabilité et ne sont pas modifiables par ce rejeu. La republication du graphe, des corrélations et du planner relit les données persistées. Elle est réessayable après import ou revue, sans réanalyse, sans nouveau claim et sans consommation de budget. Les rapprochements restent des signaux exploratoires ; ils ne prouvent ni identité ni relation métier. Le durcissement P01–P06 couvre le cycle de vie des imports, les réservations, le rejeu, les états terminaux et le framing HTTP du corps. Il ne transforme pas le protocole local en service distant ni en garantie de production. ## 18. Recherche OSINT assistée V1 — CURRENT de laboratoire Le JobStore V4 conserve le worker mono-propriétaire et ajoute des objets distincts de `local_plan.v1` et de session : plan de recherche, action, `ScopeGrant`, campagne, résultat et reçu de policy. Les admissions sont idempotentes et atomiques ; la policy expose les refus d'exclusion, révocation, expiration, identité d'enquête/plan/action ou budget. Une seed dérivée, une redirection, un CNAME ou une URL nouvelle ne propage jamais le scope. Le transport commun demeure indisponible sans backend lié. La variante libcurl est validée seulement contre le fournisseur loopback `SPECIMEN` du harness et rejette les adresses non publiques ; elle ne qualifie aucun fournisseur public ni configuration de production. Les adapters DNS, RDAP, CDX, Brave, SearXNG et page normalisent des fixtures bornées ; une `next_piste` demande toujours une nouvelle préparation et décision humaine. Le panneau Web local prépare un plan, permet l'approbation ou le refus explicite des actions, puis admet une campagne en deux vagues séparées. Les sessions et CSRF Web restent hors des contrats durables ; les tests synthétiques vérifient l'isolation des espaces A/B. Le détail canonique, les procédures de harness et les limites sont dans [OSINT_ASSISTED_RESEARCH.md](architecture/OSINT_ASSISTED_RESEARCH.md).