Ask Concord

Answers from our documentation

Ask anything about Concord. Every answer comes from our actual documentation.

Concord by IaxaI · Calibrated Identity Layer

The same person across every tool. With a confidence number an auditor can defend.

Concord by IaxaI's Entity Resolution Engine unifies users, IPs, hostnames, accounts, and hashes across disconnected security tools. No shared identifier required. Every match ships with a calibrated confidence interval, not a vendor-specific similarity score that means whatever the model felt that day.

Need calibrated identity across your stack?

The Problem

Every vendor invents its own ID. None of them agree.

Okta calls a user one thing. CrowdStrike calls them another. The firewall log only has an IP. Active Directory has aDOMAIN\userstring. Eight tools, eight identifiers, zero of them shared. Your analysts stitch the same person back together by hand, every shift, on every alert.

The Impact

Alert fatigue. Missed correlations. Audits you can't defend.

The same incident shows up as five separate alerts because nothing knows they share an actor. The auto-merge in your SIEM fires off a similarity score with no math behind it, and you find out which merges were wrong only when an examiner asks. Point-score matchers exist everywhere. None of them tell you when to trust the answer.

What Concord Does

Concord answers a single question across all of it: are these two values the same entity? It returns a calibrated probability and a coverage-guaranteed prediction set: match, non-match, or an honest "not enough signal yet." Auto-merge above a high confidence floor. Queue everything below it for human review. The math is the same. The decision is defensible.

The Outcome

One actor across your stack. One audit trail behind every merge.

Five alerts collapse into one narrative because the engine recognizes the same person. The auto-merges your platform made are reviewable, with the score, the temperature, the category, and the calibration set version written to the ledger. When an examiner asks how you know it was the same actor, the answer is a record, not a guess.

Why Calibrated

Other vendors give you a score. Concord gives you a guarantee.

Most identity matchers output a similarity score between zero and one. The number looks rigorous. It is not. There is no statistical statement attached to it, no coverage guarantee, no defensible threshold. The vendor picked 0.85 because it felt right.

Concord treats identity matching as a calibrated probability problem. Every match returns three things: a raw distribution overlap, a temperature-scaled probability tuned per entity category, and a conformal prediction set with a coverage guarantee. When the math says we don't know yet, the engine says so, instead of forcing a false binary.

How It Works

Multi-modal embeddings. Bhattacharyya distance. Conformal prediction.

Three pieces, assembled into one decision. None of them is novel on its own. The patent claim is the assembly.

Tolerance-aware encoding per entity category

IPs, ports, identities, hashes, timestamps, and categorical values each get their own tolerance semantics. Private and public IPs use class-aware subnet tolerance. Identities parse email, AD-style DOMAIN\user, UPN, and bare usernames, then compute a Soundex code for phonetic similarity. Eight categories. Eight encoders. One comparable output.

Bhattacharyya distribution overlap

The encoded values become probability distributions. The Bhattacharyya coefficient measures how much they overlap on a closed-form bounded scale. For numerics it's a standard Gaussian formula. For IPs it's a discrete subnet-membership ladder. For identities it combines Levenshtein distance, name-component matching, and Soundex. The output is comparable across categories after calibration.

Per-category temperature scaling

Raw overlap scores are not probabilities. Concord applies Platt-style temperature scaling per entity category so the output behaves like a probability. A 0.9 score actually corresponds to a 90% empirical match rate against the calibration set. We track expected calibration error honestly so a regression shows up before it ships.

Conformal prediction set with coverage guarantee

On top of the calibrated probability, Concord runs a distribution-free conformal predictor. The output isn't a number. It's a set: {match}, {non-match}, or {match, non-match} when the math says we don't know yet. The default coverage level is 95%, with the standard finite-sample correction baked in. The point isn't a fancier score. It's an honest abstain option that point-score systems don't have.

Why This Matters

Auto-merge thresholds need to be defensible to an auditor.

In a regulated environment, the question isn't whether your engine made the right call. It's whether you can show your work. Concord supports a two-tier model that's the safe pattern for regulated MSSPs and CISOs: auto-merge above a high confidence floor with the full audit trail captured, queue everything below it for human review, auto-reject on hard mismatches.

Each merge written to the ledger carries the Bhattacharyya coefficient, the temperature value, the entity category, the calibration set version, the conformal prediction set, and the decision rationale. The same record that fired the auto-merge is the record an examiner reviews months later. No screenshots. No after-the-fact reconstruction.

For MSSP Analysts

Stop swivel-chairing across CrowdStrike, Okta, Splunk, and the firewall to confirm the same person triggered all of them. Concord recognizes the actor at ingest, collapses the duplicate alerts, and writes one cross-tool narrative. Less manual stitching, faster MTTR, and a confidence number you can put in front of a client without flinching.

For CISOs and Compliance

Examiners ask how you know two records are the same person. The honest answer used to be a paragraph and a hope. With Concord it's a ledger entry: which calibration set, which temperature, which category, which prediction set, which threshold. The platform makes the case for itself, in the language a regulator already speaks.

What Ships Today

The resolver runs in production. The calibration is honest about its scope.

94.3%

Average calibrated confidence

8

Entity categories supported

95%

Default conformal coverage

The resolver is in production today (94.3% on internal benchmarks; security-domain validation in progress). The conformal predictor is implemented and live, but ships uncalibrated by default. Calibration happens during onboarding, once 30 or more labeled pairs per category exist for that environment. We don't fake a coverage guarantee against synthetic data. Until the customer calibration set is built, the conformal output is labeled uncalibrated and the platform falls back to the calibrated probability for the auto-merge decision.

Architecture

No ML in the hot path. By design.

Live identity matching has to be fast and predictable. The hot path is closed-form math: Bhattacharyya plus a single sigmoid. CPU-cheap, microsecond range, deterministic across runs. Conformal prediction at inference time is a quantile lookup, also cheap. Anything heavyweight runs out-of-band.

In the hot path

Tolerance-aware encoding, Bhattacharyya overlap, temperature scaling, and conformal prediction set lookup. All deterministic, all CPU-cheap. The same input produces the same output every time, which is what an auditor needs.

Out-of-band

Calibration runs, perturbation-based uncertainty estimates, cross-vendor batch reconciliation, and any LLM-assisted disambiguation for edge cases. None of it sits between an event and a decision in production.

Honest Scope

What this engine is not.

So nobody gets cross-examined later.

Not a graph neural net

No GNN. No embedding-based clustering on the graph. The resolver produces pairwise calibrated decisions; the knowledge graph layer aggregates those decisions into clusters.

Not LLM-driven

No LLM in the inference path. LLMs may help propose calibration labels offline, but they never make the resolution call.

Not federated yet

Every tenant calibrates alone. Cross-tenant calibration without sharing raw data is on the V2 roadmap, not in V1.

Not fuzzy matching

Fuzzy matching gives you a score. Concord gives you a calibrated probability and a coverage-guaranteed prediction set. The distinction is the patent.

Where It Fits

One engine. Three downstream consumers.

The Entity Resolution Engine sits in the data plane behind the Translation engine. It reads OCSF-normalized events, surfaces the entities inside them, and feeds three places at once.

Knowledge graph merges

Approved matches drive node merges and edge updates in the Concord knowledge graph. Auto-approve above the high-confidence floor merges directly. Mid-confidence matches sit in a governance queue with a 24-hour SLA.

Alert deduplication

The semantic dedup surface uses ER-resolved entities to collapse alerts referring to the same actor. Five separate alerts from five tools become one narrative when the engine recognizes the shared identity behind them.

Audit ledger provenance

Every resolution decision is hashed into the append-only Concord ledger with the full rationale. Compliance Auto-Packets read straight from those ledger entries when an examiner asks for evidence.

Built for regulated environments from the start

Patent-pending

The Entity Resolution Engine is one of two USPTO patent applications in active prosecution for Concord by IaxaI.

Air-gapped capable

The resolver runs on CPU, on-prem, with no external API dependency. Suitable for client environments that can't send telemetry to the cloud.

Ledger-anchored

Every match decision (score, temperature, category, conformal set, calibration version) written to the hash-chained Concord audit ledger.

Stop reconciling. Start trusting one timeline.

30-minute walkthrough. Your tools. Your tenants. Your audit cycle. We will show you exactly where Concord earns its keep.