Our principles
Enterprise AI should be open to choice.
AI Exchange is built around a simple idea: valuable expertise should be portable, discoverable and commercially accessible without forcing builders or buyers into a single technology or provider ecosystem.
- Build with the technology you choose.
- Run where your requirements demand.
- Keep control of your data and intellectual property.
- Exchange expertise on fair terms.
01 · EXECUTION
The asset decides where it runs.
AI Exchange does not dictate the execution environment and does not become your runtime. A capability declares what it needs — residency, hosting, approvals — and you deploy it where your constraints say it belongs.
Discovery, evidence and fit; not a proprietary runtime.
Browse capabilities and their requirements02 · BOUNDARIES
Your infrastructure. Your data. Your boundaries.
Fit is assessed against your organization's context — where data may be processed, which models are permitted, who must sign off. Reusable evidence shortens diligence; it never replaces your own security, data and legal review.
The exchange enables choice. It does not define your perimeter.
How fit is assessed against your context03 · DISCLOSURE
Open when it makes sense. Protected when it matters.
A public capability page shows what a capability does, for whom, what it needs and what has been established. The full dossier — every evidence record, the assessment detail, the technical description — is read with an account. Builders publish under the name they choose; the exchange holds the verified identity and intermediates the relationship.
What is not declared stays visibly undeclared. Nothing is inferred.
Create an account to read full dossiers04 · EVIDENCE
Know what you're deploying.
Every statement about a capability carries the class of evidence behind it: declared by its builder, mechanically verified by exchange tooling, expert-reviewed, attested by a third party, observed by the exchange, or reported from a real deployment. Where nothing has been established, the record says so. A provider is shown as verified, not verified or demo — never assumed.
Evidence is typed, never summed into a score. No certification is claimed that does not exist.
DeclaredVerifiedExpert-reviewedAttestedObservedBuyer-reportedAbsent
How trust and evidence work05 · PACKAGING
Package the reusable core. Keep integration explicit.
Reusable capability can travel: the agent, model, workflow or blueprint that solved a problem once can be evaluated for the next one. Integration with your data, security, processes and infrastructure stays contextual — so a capability declares its requirements, dependencies and deployment characteristics rather than hiding them, and the implementation work that remains is stated, not assumed away.
Reusable IP creates leverage. Explicit integration makes it usable in context.
The reusable core and the implementation delta06 · DEMAND
Start with what already works.
Before starting another project, describe the outcome you need and see whether reusable capability already addresses it — and how well it fits your context. If nothing fits, the need does not end there: a buyer can activate it as a sanitised brief that builders and partners propose against, and the buyer selects.
Has somebody already solved enough of this that you should not start from zero?
Start with the business problem07 · REUSE
Great expertise should create value more than once.
Valuable domain expertise is rebuilt again and again inside consulting engagements, internal projects and isolated implementations. Specialist capability should be reusable across contexts without losing its attribution, its dependencies or the boundaries around its use.
Build it once, well. Let it be found, evaluated and reused.
Publish what you already solvedBring what you know. Find what you need.
Independent intelligence, fairly exchanged.
These are the rules the product is built around. They are meant to be challenged by the people using it — leaders, builders and partners — and refined into something practical.