How Elidian works
The registry your agents query and your governors control.
Elidian maintains listings bound to verified credentials, jurisdiction and policy attributes. An agent submits a capability query; the eligibility filter returns only pre-authorised candidates; every event is logged.
A sourcing task, end to end
One query, from rule to logged shortlist.
The path a single sourcing request follows through the product.
Set the eligibility rules
A named governor defines the Eligibility Policy in the admin surface — policy-compatibility rules, authority limits and value thresholds per querying agent — before any agent runs a query.
Onboard and verify a listing
A company submits a Counterparty Listing. The verification service checks its Credentials against submitted and third-party sources; clear cases are certified, and ambiguous ones open a Verification Case for human approval.
Agent submits a capability query
The AI colleague asks the directory for a required capability. The matching engine returns candidates from registered listings using a normalised taxonomy, so comparable capabilities surface together.
Filter to a cleared shortlist
The eligibility filter removes candidates outside the governor's rules and authority limits. The agent receives only counterparties it has been pre-authorised to consider — nothing further.
Log the discovery event
The query and the selection are written to the audit trail as a Discovery Event, so a later procurement or governance review can reconstruct who was eligible and why.
The modules
The parts that produce an eligible result.
Each module does one job on one object; together they answer a single question before a transaction begins.
Verified Listings Registry
Structured Counterparty Listings bind each company's agent capabilities to verified credentials, jurisdictional metadata and machine-readable policy attributes. AI colleagues maintain the records; a governor approves what is certified.
Capability Matching Engine
Incoming agent queries are matched to registered listings through a normalised capability taxonomy, so a request stays comparable across companies that describe the same capability in different words.
Credential Verification Service
Each Credential on a listing is checked against submitted and third-party sources. Elidian consumes upstream identity and credential assertions rather than minting an identity of its own.
Eligibility & Policy Filter
The governor-configured Eligibility Policy decides which counterparties a given agent may consider, applying policy-compatibility attributes, authority limits and value thresholds per querying agent.
Trust & Reputation Records
Reputation records built from logged interaction outcomes give each listing a trust standing that changes over time, rather than a single one-off pass or fail.
Onboarding & Approval Workflow
New counterparty onboarding and ambiguous or high-stakes Verification Cases route to a named human for approval in the admin surface, never to auto-approval.
Staleness & Consistency Scanner
AI colleagues continuously scan listings for stale, expired or inconsistent credentials, flagging or suppressing those that should no longer be treated as eligible.
Audit & Governance Log
Every Discovery Event — what was queried, returned and selected — is recorded so a procurement audit, dispute resolution or governance review has a complete trail to retrieve.
What runs automatically, and where a person decides.
What the agents do, and what a person answers for
AI colleagues run the day-to-day work of the directory. They verify listings against submitted and third-party credential sources, match incoming queries to registered listings, and normalise capability taxonomies so a request means the same thing across companies that word it differently. They maintain reputation records from logged interaction outcomes and scan continuously for listings whose standing has lapsed. Each querying agent works inside the eligibility rules, authority limits and value thresholds its governor has configured, and receives only counterparties it has been pre-authorised to consider.
Accountable people keep the functions that carry fiduciary weight. A named governor sets the eligibility and policy-compatibility rules, approves the onboarding of a new counterparty, and adjudicates a disputed verification or reputation entry. Ambiguous or high-stakes cases escalate to that person instead of clearing on their own. The agent proposes candidates; the governor decides what the venture treats as trustworthy, and owns the outcome.
Where the boundaries sit
Elidian discovers and verifies standing before a transaction begins, and stops there. It does not negotiate, contract or settle — those sit in adjacent layers — and it holds no funds, which keeps it outside payment-intermediation risk. It relies on verified identity and credential assertions from the upstream identity layer rather than issuing identity itself. Every discovery and selection event is retained, so a governor keeps oversight and a procurement or risk team has an audit trail to produce on demand. The eligibility rules, approval gates and event logs are designed to meet DIFC-compatible oversight expectations.
Where the product is heading
The direction is set by what can be built honestly in sequence, not by a roadmap of promises. In the near term the core flow runs end to end — query and shortlist, eligibility filtering, credential verification, human onboarding approval and audit logging — seeded with a modest set of verified listings, because usefulness does not depend on the ecosystem being large. Next, cross-organisation listings and query volume grow, reputation records accumulate from real interaction outcomes, and the capability taxonomy is normalised further across companies. Further out, the directory begins to function as a shared dependency that other inter-agent infrastructure can build against, with trust standing informed by accumulated outcomes and federated governance in place. We frame this as direction, and we name willingness to pay and the response of capable incumbents as questions still being tested rather than settled.
How the directory behaves in practice.
See how a counterparty is screened before engagement.
Bring one sourcing task and one candidate. We will walk the query, the eligibility filter and the logged event with you.