@lssm/lib.osint-runtime

Provider-neutral OSINT lifecycle and ingestion logic. The runtime separates source discovery, qualification, ingestion, and revalidation, applies scoped fail-closed policy, guarantees idempotent receipts and evidence-backed assertions, filters suppression records, and projects only policy-eligible facts into the existing knowledge system.

Concrete persistence, object storage, embedding, provider web access, queues, and transports are injected through ports. This keeps company, job, and people systems independently deployable while allowing composed deployments such as hirly.france.internship-apprenticeship.

Source lifecycle mutations are revision-fenced and return append-only, idempotent receipts containing the exact resulting source manifest. Durable workers can query a receipt by idempotency key, resume an interrupted revalidation, and reject stale work without repeating a committed effect. Canonical request digests and bounded owner leases prevent concurrent evaluators. Each transition receipt binds the claim key, owner, and monotonic attempt so a store can validate the live lease in the canonical mutation transaction; expired claims can be reclaimed while completed claims remain terminal.

Knowledge projections carry exact source versions, evidence locators, ACL grant references, purpose, index generation, and suppression references. Query receipts bind retrieval results back to their evidence and policy decision; knowledge remains a derived retrieval aid and never authorizes a fact or action.

The operation runtime defines the provider-free request, queue, fence, authority, read, and mutation ports used by every transport composition. Canonical request fingerprints bind the complete actor, scope, grants, parameters, and input so a worker can reauthorize the original effect immediately before executing it.

Ingestion accepts an abort signal and propagates it into the source connector, then rechecks cancellation before object persistence and materialization stages. Known data-isolated deployment profiles are enforced automatically from the request deployment ID across managed API, MCP, and worker surfaces. A managed worker using the Hirly profile must attest exact OSINT_QUEUE_NAMESPACE, OSINT_INDEX_NAMESPACE, OSINT_CREDENTIAL_NAMESPACE, OSINT_REGION, OSINT_NETWORK_POLICY_REF, OSINT_DATA_STORE_REF, OSINT_OBJECT_STORE_REF, and OSINT_EXPORT_POLICY_REF bindings before startup. Namespaces must be distinct, and profile entity, jurisdiction, purpose, and concurrency limits are fail-closed.