The question is eligibility. Is this actor allowed to do this thing, right now, in this context? Most identity platforms sell you verification and stop, because verification is the easy half. The hard half is deciding what a verified party may do, and proving afterwards that the decision was right.
Every KeyFlux product exists to answer it. Verifiable Credential Core answers it for people and organisations. REMIT answers it for agents and machines.
Two families, two engines. Each implements the decision its own way and always has. Core evaluates eligibility over a presented credential. REMIT evaluates eligibility over a proposed action. Different code, different data, different runtime. What they share is the question, the standards and the discipline about evidence. We would rather say that plainly than draw you an architecture that does not survive diligence.
The company thesis
Verification confirms that a credential, or a token, or a key is real. It tells you the thing in front of you has not been forged or tampered with. It does not tell you whether the party holding it is allowed to do the thing they are trying to do.
That second question is eligibility, and it is the one the business actually cares about. Every KeyFlux product exists to answer it. For people and organisations through Verifiable Credential Core. For agents and machines through REMIT.
People and organisations
Does this holder qualify, given the verified attributes they just presented?
Answered by Verifiable Credential Core, through its eligibility engine, Resolve.
Agents and machines
Is this agent, this action, this request eligible right now, given the conditions?
Answered by REMIT, through its own policy surface.
Same question, two surfaces, on purpose. Core answers it over a presented credential. REMIT answers it over a proposed action. They are separate implementations in separate code, and neither borrows the other's runtime. Whether they ever converge is a decision we have not made, so we will not draw you a diagram that says they already have.
How Resolve decides eligibility in CoreEligibility for people and organisations.
Core issues, holds and verifies the credentials that people and organisations carry, and then decides whether the holder qualifies. ISO mdoc, W3C VC and SD-JWT VC through one integration, on top of the ISO and W3C stacks.
One engine, two markets. Foundational issuance for governments, national PKI and national identity services: mDL and eID at population scale, self-hosted, and sovereign by definition. Derived issuance for banks, telcos, insurers and credit bureaus, which take a government-issued ID and derive a credential of their own. Self-hosted on either stack, or run through the managed portal for smaller implementations.
What you get
The eligibility engine inside Core. Policy evaluated deterministically against verified facts, returning a decision you can act on and defend. The decision, not the proof.
Cross-border and cross-issuer trust routing.
The customer-facing identity surface over a derived credential.
The holder side, included in both markets. Ship the KeyFlux app, or embed the SDK in your own. Banks and telcos usually take the second.
A function of the wallet. The wallet is the secure file vault for signed documents, so signing and holding sit together on the holder side rather than as a separate service.
Standards monitoring across the framework corpus, included rather than sold separately.
Eligibility for agents and machines.
REMIT decides whether a proposed machine action is eligible right now, given the conditions, and then issues short-lived scoped authority for exactly that action. Eligibility is what it decides. Authority is what it issues.
REMIT is also the human trust chain. Every machine action is pinned to a person or an organisation with the authority to have permitted it, inside a scope, inside a window, with a record that stands up afterwards. Nothing standing, nothing shared, nothing that outlives the task.
Three lines
Self-hosted, in-cluster, Kubernetes-first. The full pathway set and the full policy surface, running in your own tenancy.
Hosted SaaS, scoped to CI/CD integration for DevOps pipelines, with a free community tier. Cloud imports the spine core rather than reimplementing it, so there is one policy engine behind both, not two.
Financial authority for non-human actors. The mandate is a credential, enforcement covers every rail, and we never take custody. Hybrid deployment: a self-hosted authority plane plus a hosted mediation and receipt service, sold as one product.
One seam is real today. Transact uses credential verification to establish who is paying. SPINE does not verify credentials for AI agents. Anything beyond that is a roadmap choice, not a description of what runs now, and we will tell you which is which.
Three dimensions, no surprises.
Your integration surface. What you connect, and at what scale.
Optional capability. TrustGrid, Sign and the vault, and KeyFlux ID against a Core tier. Each SPINE target class beyond Kubernetes. Each Transact rail adapter beyond the first. A module earns a line only if you would decline it.
Multiplies. You pay in proportion to the decisions you make.
Resolve is never a priced module, because eligibility is not an add-on. It is the product.
See both engines running against your own credentials and your own rules.
Request a Demo