Ask Concord
Answers from our documentation
Ask anything about Concord. Every answer comes from our actual documentation.
Concord by IaxaI · Calibrated Identity Layer
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.
The Problem
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
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
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
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
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
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
94.3%
Average calibrated confidence
From a controlled product-matching benchmark on Concord's resolver. Internal benchmarks; security-domain validation is in progress. The number is honest within its scope and does not yet generalize to security entities.
8
Entity categories supported
Network address, network port, temporal, identity, hash, geolocation, severity, categorical. Each category has its own tolerance semantics and its own per-category calibration.
95%
Default conformal coverage
The conformal predictor ships with a 95% coverage default and the standard finite-sample correction. Coverage guarantees activate once 30+ labeled pairs per category are available. Calibration happens during onboarding.
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
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
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
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.
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.
30-minute walkthrough. Your tools. Your tenants. Your audit cycle. We will show you exactly where Concord earns its keep.