Skip to main content

What OMAR does, and how honestly we say so.

OMAR's engineering doctrine forbids describing a roadmap item as a live capability. Every feature below carries one of four truth labels, and the same rule governs this page.

Proven
Implemented, covered by automated tests, and exercised end to end through the analyst interface in a dated verification ledger with independently re-hashed evidence.
Implemented, needs configuration
The code path exists and is tested, but it requires real credentials, contracts, external services, or approvals before it operates.
Qualification target
The mechanism exists but has not yet been proven at the required scale, rigor, or with independent human analysts.
Planned
Not implemented. Described only as future direction.

Two further rules apply to everything here. OMAR retains no mock or seeded intelligence: a fresh installation is empty. And the current build is an operational alpha under production-pilot hardening. It is not yet V1.0.

The catalog.

Case workspace and conversation

Proven

The organization, project, case, and chat hierarchy; a streaming conversation that initiates and explains work; a persistent investigation status; and guided next actions.

How it works

  • Every analyst message creates a run with fixed states. A client cannot skip to completion.
  • Run events are an ordered ledger in PostgreSQL, streamed over server-sent events with reconnect from the last sequence. Replay depends on the ledger, not a browser transcript.
  • Follow-ups such as “what products does that company operate?” bind to the exact prior plan, focus, or evidence, and pause if more than one candidate could satisfy the reference.

What it represents

The case file and the analyst's log, made durable and replayable.

Deterministic planning and bounded collection

Proven

Turns an ordinary-language requirement into an inspectable, editable, versioned, policy-authorized search plan with exact per-source queries, then executes it within explicit budgets.

How it works

  • A rules-based parser extracts the directive, subjects, predicates, required and excluded terms, domains, and date constraints. Imperatives and filler never become subject names.
  • The plan stores both the logical query and the exact transport query sent to each provider. A provider that cannot honor an operator reports it unsupported rather than silently broadening.
  • Sensitive actions keep explicit approval regardless of mode: source activation, sensitive downloads, scheduled monitoring, entity merges, notifications, exports, and imports.

What it represents

Collection planning and tasking. The plan is the collection order; the coverage ledger is the collection report.

Source connectors and the collection contract

Proven

Governs every external source through one connector contract and one evidentiary standard, with honest per-source health and authorization states.

How it works

  • Connectors yield material. They never create facts or graph edges.
  • Raw bytes preserved, redirects denied except by the validated capture path, byte ceilings enforced, response schemas validated, fail-closed when a credential or authorization reference is missing.
  • Source availability requires both administrator authorization and actual provider health. Completing configuration never auto-enables a source.

What it represents

Collection management: source registration, authorization, tasking, and reporting, with the rights of each source recorded rather than assumed.

Status note

About a dozen adapters proven live; three need the customer's credentials; live certification is per deployment.

Evidence preservation and lineage

Proven

Preserves original bytes before anything parses them, and keeps every derived object pointed back at the original.

How it works

  • Seal, store, commit the evidence record, then parse. Parsing failure cannot erase received evidence.
  • Object keys are content-addressed and case-scoped. Reads re-hash and reject on mismatch.
  • Discovery metadata is classified separately from a preserved publisher page. Analysis is disabled on discovery-only material until the page is captured.

What it represents

Preservation before examination, applied to volatile public content.

Status note

Application immutability is not storage WORM enforcement. Object Lock, versioning, and key custody are deployment responsibilities.

The controlled browser

Proven

A real, audited, isolated Chromium session for navigation and explicit evidence capture, with agent and analyst control ownership.

How it works

  • Every request is routed through a public-address validator; downloads are disabled; workers hold no control-plane secrets.
  • Explicit capture stores the original response bytes, the rendered HTML, and a full-page screenshot as three separately hashed objects.
  • A capture whose malware scan is not clean is refused as evidence.

What it represents

Controlled, attributable web exploitation. Capture is a deliberate evidentiary act.

Status note

Qualification target for multi-user scale and the ten-second interactive target.

Document and media exploitation

Proven

Preserves uploaded files as evidence, processes them in an isolated no-egress worker, and produces reviewable derived artifacts with exact lineage.

How it works

  • The original upload is stored and hashed first, then malware-scanned. When scanning is unavailable, the file is quarantined rather than given a pretend extraction.
  • PDF, DOCX, CSV, JSON, GeoJSON, STIX 2.1, EML, MBOX, PNG and JPEG with OCR, audio and video with offline transcription, and plain text.
  • English is the qualified baseline for OCR and transcription. Other languages are heuristic or unqualified.

What it represents

Document and media exploitation with chain of custody.

Deterministic extraction and governed relationships

Proven

Produces entity, mention, event, and relationship proposals from preserved evidence, each citing an exact span, under a governed predicate vocabulary.

How it works

  • Relationship proposals require a bounded subject-to-cue-to-object statement, not co-occurrence. Each cites exact spans and the sealed evidence digest.
  • Nine governed predicates today. Anything else is rejected. Adding one is a reviewed code and schema change, never a source or model decision.
  • First-party claims are labeled first-party rather than presented as independent confirmation.

What it represents

Structured extraction under an ontology the organization controls.

Identity resolution without silent merges

Proven

Groups ambiguous mentions into candidate identity groups, scores them transparently, and requires an explicit, reversible analyst decision before anything merges.

How it works

  • Every component, compared signal, and contradiction is exposed. The score is explicitly not a calibrated probability, and the interface says so.
  • Review outcomes are merge, separate, reject, or abstain, each with rationale and a source-backed evidence matrix. The scorer never merges anything.
  • A split reverses a prior merge without deleting mentions, evidence, or review history.

What it represents

Entity resolution with the analyst as the deciding authority. In a live exercise OMAR kept an airline executive and a pianist with the same name separate.

Status note

Qualification target: a published precision and abstention measurement on a governed hard-case set.

Contradictions and corroboration

Proven

Records where evidence disagrees, where it is insufficient, and where repetition is being mistaken for corroboration.

How it works

  • Both sides and their passages remain visible. A missing confirmation is never automatically a contradiction, and disagreement is never averaged into one score.
  • Multiple records do not imply multiple independent sources. Analysts inspect lineage before treating repetition as corroboration.

What it represents

Analytic rigor about conflicting information and source independence.

Graph, timeline, map, and narrative

Proven

Presents the same reviewed case across relationship, temporal, geospatial, and narrative views, synchronized around one active item.

How it works

  • Rejected and unreviewed records never enter the graph. Accepted records whose evidence references are dangling fail the projection closed rather than disappearing.
  • Reviewed event time is distinct from publication and retrieval time. The map plots only source-cited points; nothing is geocoded or inferred.
  • Empty views stay empty and state what reviewed input is missing.

What it represents

Link, temporal, and geospatial analysis as views of one evidentiary record.

Translation and optional AI acceleration

Proven

Uses a model, when one is configured and evaluated, to accelerate query expansion, entity extraction, English translation, and contradiction discovery, while keeping the model outside the authority boundary.

How it works

  • Every model request records provider, model, revision, parameters, input and output digests, and token usage.
  • Every result is a persisted proposal with an explicit accept or reject route. Nothing is applied automatically. The workflow runs without a model.
  • AI cannot authorize a source, establish that two mentions are the same person, accept an assertion, create an uncited claim, or modify preserved bytes.

What it represents

AI as a replaceable accelerator with full provenance and human oversight.

Status note

Planned: clustering, drafting from accepted claims, and collection-gap assistance, each as a bounded slice.

Monitoring and change detection

Proven

Turns an accepted investigative focus or area of interest into a durable, bounded watch mission that reports genuine change or genuine absence of change.

How it works

  • Each cycle collects, seals, and builds a snapshot. Comparison classifies it as baseline, no change, changed, or below threshold, with added and removed records.
  • A source failure is recorded as a failure, never converted into a successful unchanged result. A transport timestamp changing is not new intelligence.

What it represents

Persistent surveillance of an accepted subject with checkpoints, deduplication, and receipts.

Status note

Proven for three durable cycles. Qualification target: worker-loss recovery and 500 end-to-end watchlists.

Notifications

Proven

Delivers approved alerts and mission receipts by signed webhook or SMTP, with receipts, retries, dead-letter handling, and revocation.

How it works

  • Destinations are case-bound, allowlisted, marking-limited, approval-gated, and revocable.
  • A per-destination marking ceiling prevents content above the destination's clearance from being sent.

What it represents

Dissemination under handling rules, with proof of delivery.

Status note

Proven to controlled sinks. Qualification target: an external authenticated TLS mail service and an approved external webhook.

Claim-level reporting

Proven

Builds cited briefs from accepted claims only, validates every citation against re-hashed evidence before publication, and renders one validated version to HTML, PDF, and DOCX.

How it works

  • Analysts edit only claim wording while exact-span citations stay locked. Any edit invalidates prior validation.
  • Validation re-reads the referenced objects, recomputes SHA-256, and checks that the quoted text equals the exact slice of the source. The result is recorded as exact_span_and_sha256.
  • A revalidation path re-checks a published brief later, so a report can be shown to still correspond to preserved evidence.

What it represents

Sourced analytic production. The brief can answer “show me the evidence for that sentence” for every material claim.

Collaboration, roles, and shift handoff

Proven

Controls who can see and act on a case, and lets one analyst hand a case to another without losing scope, uncertainty, or the active evidence.

How it works

  • Roles: organization administrator, source administrator, project lead, analyst, reviewer, auditor. Membership changes are versioned, rationale-bound, and audited.
  • A shift handoff seals an immutable snapshot bound to an authorized recipient. Acknowledgement is attributed and version-bound.

What it represents

Continuity of operations across shifts and teams.

Status note

Proven across two distinct OIDC subjects. Qualification target: independent human analysts.

Signed transfer packages and cross-domain movement

Proven

Exports selected evidence and reviewed records as a signed, hashed package that a separate deployment can verify and import under approval, without any direct network bridge.

How it works

  • The manifest is signed as detached CMS SignedData with an embedded certificate whose fingerprint must match a trusted anchor.
  • Import is two steps, verify then accept, and acceptance is approval-gated.
  • There is no OMAR service that moves a package between domains. An approved external process does. OMAR is not a cross-domain solution.

What it represents

Governed evidence exchange in the pattern accreditors expect: hash, sign, verify, approve.

Status note

Production PKI, certificate chains, and revocation are customer integrations.

Retention and case settings

Proven

Records a reviewed retention policy per case with legal hold, minimum retention, and indefinite disposition, and schedules review without ever deleting automatically.

How it works

  • Automatic deletion is hard-coded off. Actual disposition needs separate rights review and an approved workflow.

What it represents

Records management that respects legal hold and source rights, without promising compliance the software cannot deliver by itself.

Identity, policy, and security

Proven

Authenticates real users, authorizes every consequential action through an explicit policy engine, and defends collection and processing against hostile content.

How it works

  • OIDC with PKCE. OPA policy evaluates actor, organization, case membership, role, marking clearance, purpose, source status, approval, and deployment domain. Required OPA unavailability fails closed.
  • Source pages, uploads, OCR, transcripts, translations, and model responses are data. Models receive delimited content and no credentials or tools.
  • Digest-pinned images, hash-pinned dependencies, signed images and charts, SBOMs, and a signed offline install bundle.

What it represents

Zero-trust style authorization on every action, with the audit trail a regulated customer will ask for.

Status note

Explicit gaps: PostgreSQL row-level security is not yet installed; object immutability needs storage-side controls; the default local profile is not production hardening.

Deployment profiles and platform

Proven

Runs as a lean operator core with optional capabilities, in three deployment profiles: SaaS low side, self-hosted low side, and self-hosted high side.

How it works

  • PostgreSQL with PostGIS and an S3-compatible object store are authoritative. Search and graph projections are rebuildable.
  • A readiness endpoint aggregates nineteen components with signed, freshness-checked receipts and reports pilot-ready only when every gate holds.
  • High-side deployments deny public collection at the code, policy, and network levels and use local models only.

What it represents

A platform designed for procurement environments that ask where the data lives, who can reach it, and how it is recovered.

Status note

Proven on a retained three-node k3s runtime. Qualification target: full-scale capacity and recovery on the release candidate. Formal high-side accreditation is a separate program.

Audit and observability

Proven

Records who did what, on which resource, with what decision, and exposes operational telemetry without crossing domain boundaries.

How it works

  • Audit and review events are append-only with actor, action, resource, decision, before and after state, reason, and time.
  • Telemetry isolation between tenants and domains is verified by script.

What it represents

The record a reviewer, auditor, or attorney will ask for.

What OMAR is not.

These boundaries are part of the product, not disclaimers to hide. They are what make OMAR defensible in front of a reviewer, an auditor, an attorney, or a customer.

  • Not a promise to find “all information” on a person, company, or event.
  • Not a data broker, a people-search product, or a source of purchased identities, breached credentials, or illicit access.
  • Not a license to scrape sources contrary to law, contract, terms, or policy. When an official API or contract is unavailable, OMAR does not fall back to prohibited scraping.
  • Not a system that converts model output into fact. AI proposes; deterministic rules and analysts decide.
  • Not a graph that turns proximity into fact. A graph edge is a projection of a reviewed assertion, never the assertion itself.
  • Not an autonomous identity-resolution or attribution authority.
  • Not a cross-domain solution or a direct bridge between security domains.
  • Not a covert account-interaction, exploitation, purchasing, or dark-web transaction platform.

What V1.0 means.

OMAR V1.0 is a supportable self-hosted-low production pilot on a three-node Linux cluster. It is reached only when twenty-five stopping conditions hold on a clean installation. The ones that matter most to a buyer:

  1. 01Zero investigative data at start; no retained environment contains mock intelligence.
  2. 02A new analyst completes the primary workflow without undocumented product knowledge.
  3. 03At least ten useful connector types pass current live acceptance across required source classes.
  4. 04Identity disambiguation prevents silent common-name merging.
  5. 05Every accepted analytical object resolves to preserved evidence, and at least one cited brief revalidates every material claim after storage.
  6. 06A watchlist completes three durable cycles and a real approved notification is delivered and receipted.
  7. 07Real OIDC identity and authorization are active; tenant, marking, policy, and high-side isolation tests pass.
  8. 08Backup, restore, failover, migration, and rollback exercises pass; signed images, charts, SBOMs, and installation artifacts are reproducible.
  9. 09The readiness endpoint reports pilot-ready and a reproducible proof package lets another analyst repeat the demonstrations.

Performance and scale figures are release targets for the declared reference cluster, not guarantees for a laptop. Workload, speed, and coverage improvements will be claimed only after a preregistered study passes. Until then they are hypotheses. Status labels on this page: proven, implemented, needs configuration, qualification target, planned.