The Kordane platform
Choose the workflow. Keep control of the data.
Start with a demo of the task you need: search private knowledge, extract documents, transcribe speech or handle customer conversations. We scope a pilot around that task, your deployment constraints and agreed success criteria.
Kordane Cortex
Put your knowledge to work.
Find the answer in your own information. Turn documents into structured data, search internal knowledge and make speech useful, with the source always close at hand.
Assist, Extract and Voice available in pilots · additional capabilities planned
Explore CortexAxon by Kordane
Conversations that move work forward.
Bring knowledge, automated workflows and people into the same conversation. Give customers a useful answer and your team the context to take the next step.
AxonCX available in pilots · Live Agent in development
Explore AxonKordane BoundSense
Your information. Your rules.
Set the terms before information reaches a model. Protect sensitive values, decide where a request can run and keep a record of the decision.
Demonstrated in the browser · available in pilots
Explore BoundSenseKordane Forge
Match the model to the job.
Make model choice an engineering decision. Compare quality, latency and cost against your task, then find the smallest permitted model that meets your requirements.
Training and evaluation available in pilots · selection, runtime and distributed evaluation planned
Explore ForgeHow it connects
The work, the model
and the rules.
Follow a task through the platform. Explore which product handles the request, sets permission, evaluates the model and keeps the record.
BoundSense decides permission. Forge decides model sufficiency. Cortex and Axon perform application workflows.
How one controlled execution is decided.
Model evidence is prepared before runtime. At runtime, BoundSense decides whether and where the task may run, the Forge-selected model performs it inside that permission, the response is inspected on the way back, and every product contributes to one reviewable decision.
Available in pilotsBoundSense’s crossing decision is demonstrated on this site; the surrounding steps are available in pilots and configured per deployment.Module-level status stays on each product page.
An application states the work it needs done and the threshold a model must clear to be sufficient for it. This happens before runtime, not on every prompt.
BoundSense decides which candidate models and which environments are permitted for this task and information class. Everything after this point works inside that set.
Forge measures each permitted candidate against the task threshold. Forge may narrow the permitted set to the candidates that pass. It can never widen it.
The selected candidate, the rejected alternatives, the measured results and the fallback path are recorded so the choice can be reviewed afterwards.
Permitted to leaveSelected model · rejected alternatives · measured results · fallback path
Runtime consumes the record, not a fresh benchmark. A live request does not re-evaluate every candidate model.
Someone asks a question, submits a document, or continues a customer conversation.
Cortex or Axon assembles the request from approved sources and context. It may request capability; it cannot grant itself any.
Sensitive values are found before anything moves, and each one is assigned a class the policy can reason about.
The active profile decides per class what may cross, in what form, into which environments, and whether a named person must approve first.
Values that may cross in shape but not in substance are tokenised. Values that must stay put are contained. Prohibited crossings are refused outright.
Crossing permitted, after transformation
The model that runs is the one the selection record names, and it is still inside the set BoundSense permitted. A failed threshold cannot be overridden downstream.
Local, private, or approved external: whichever the policy decision allowed for this information class.
Nothing goes straight back to the application. The return path is governed exactly like the outbound one.
An unknown or malformed token, or a sensitive value the model produced on its own, stops the crossing rather than reaching the user.
Response inspected · release permitted
Tokenised values are restored locally where policy allows, and the application presents the answer with its evidence or carries it on into the workflow.
BoundSense contributes the crossing decision, Forge the selection basis, and the application its workflow and source evidence, combined into a single record a reviewer can read.
Permitted to leavePolicy decision · classification · transformation · selection basis · response provenance
Step 1 of 16
Inspect each part of this diagram
An application states the task it needs performed and the acceptance threshold that would make a model sufficient for it.
BoundSense establishes which candidate models and which execution environments are permitted for this task and information class. Nothing downstream can widen this set.
Forge evaluates the permitted candidates against the declared acceptance threshold. Forge may narrow the permitted set; it can never widen it.
The selected candidate, the rejected alternatives, the measured results and the fallback path, recorded so the choice can be reviewed later.
A person asks a question, submits material, or continues a conversation inside an application.
The application assembles the task from approved sources and context. It may request capability; it cannot grant itself any.
BoundSense finds sensitive values in the request and assigns each one a class the policy can reason about.
The active policy profile decides per class what may cross, in what form, into which environments, and whether a person must approve.
BoundSense acts on the decision: tokenise or redact what may not cross in its original form, contain what may not leave at all, refuse what is prohibited, permit the rest.
The task runs where policy permits, on the Forge-selected candidate, which remains inside the BoundSense-permitted set.
The answer is checked before anything is restored: an unknown or malformed token, or a sensitive value the model produced on its own, stops the crossing.
Tokenised values are restored inside the environment where they came from, only where the policy profile allows restoration.
Cortex presents the result with its supporting evidence, or Axon carries it on into the conversation or workflow.
Each product contributes its own evidence to a single record: what was permitted and why, which model was selected and on what basis, what returned, and what the application did with it.
Private distributed evaluation.
Evaluate permitted candidate models across private or isolated datasets without centralising their raw evaluation examples. BoundSense-authorised nodes control what runs locally and what metrics or evidence may leave. This is distributed evaluation, not federated training.
PlannedPlanned architecture. Not implemented, and not available in pilots today.Roadmap intent recorded in the Forge repository; no implementation is claimed.
One immutable package identifies the task, the candidate, the runner and the metrics, so every node evaluates the same thing and the run can be repeated.
Each node authorises independently: which package, which candidate, which local dataset reference, and what may leave. One node’s permission never extends to another.
Each environment runs the candidate against its own dataset, under its own access controls, and records complete evidence locally.
The examples themselves are not centralised in order to score them. They remain inside the approved environment that holds them.
Raw examples contained locally
Each node emits the metrics, findings and evidence its local policy explicitly allows, and nothing else.
Permitted to leaveMetrics · safety findings · failure counts · local evidence identities
Aggregation records which nodes participated, which were unavailable and which were excluded, so a partial run is never read as a complete one.
Global, per-node, subgroup and jurisdiction criteria are checked in their own right.
Global threshold: passed
One required environment falls below its threshold. The global average still passes. That is exactly the case the design exists for.
Required node threshold: failed
A passing global metric does not release promotion on its own. The candidate is held until the required node passes or the task specification changes.
Promotion: held
One record links the aggregate result to each node’s local evidence identity. Failed and refused evaluations are not rewritten to make a candidate look successful.
Step 1 of 10
Inspect each part of this diagram
Forge holds the task specification, the candidate set BoundSense permitted, and the thresholds each candidate must clear.
One immutable package identifies the task, the candidate, the runner and the metrics. Each node evaluates the same thing, and the run can be repeated.
BoundSense authorises which package, candidate and local dataset reference may run at this node, and what may leave it.
The candidate runs against the local evaluation dataset inside the customer-controlled environment. Complete evidence is recorded locally.
The same authorisation is made independently at each node; one node’s permission does not extend to another.
A second independently controlled environment runs the same package against its own dataset, under its own local policy.
An isolated environment is authorised on the same terms, with tighter limits on what may leave.
An isolated environment participates without its raw evaluation examples travelling anywhere. Only what local policy authorises leaves.
Each node emits only the metrics, findings and evidence its local policy allows. Raw examples are not among them.
Forge combines what returned, recording which nodes participated, which were unavailable, and which were excluded.
Global, per-node, subgroup and jurisdiction thresholds are checked separately. A global average cannot absorb a required node failure.
Promotion is released only when every required threshold passes. Otherwise the candidate is held or rejected, and the reason is recorded.
One record links the aggregate result to each node’s local evidence identity. Failed and refused evaluations are not rewritten.
Governed distributed retrieval.
Query approved private sources across multiple controlled environments. Retrieval remains local, while only policy-authorised evidence, excerpts, structured facts or local answers may return.
PlannedPlanned architecture. Not implemented, and not available in pilots today.Roadmap intent recorded in the Cortex repository; no implementation is claimed.
An analyst or a workflow asks something that may need evidence held in more than one controlled environment.
The question itself is classified. BoundSense decides which nodes and sources are eligible, and what the query must look like before it travels.
An environment that was not authorised for this question never sees it.
Each node searches its own sources under its own access controls. Nothing is pooled into a central index to answer the question.
The corpora themselves stay inside their approved environments, with their own retention and deletion rules.
Source corpora contained locally
Excerpts, structured facts, a local answer, or a provenance reference: whichever the node’s policy permits, and nothing beyond it.
Permitted to leaveExcerpts · structured facts · local answers · provenance references
Duplicate findings, contradictions between nodes, unavailable nodes and source provenance are resolved before anything is composed.
Each factual claim points to evidence that actually supports it, with its node and source provenance attached.
Answer released with citations
A required node that did not answer, or evidence too thin to carry the claim, is stated plainly rather than filled in.
Required node unavailable · answer qualified
The query decision, node participation, citations and stated limitations are recorded together with the answer.
Step 1 of 10
Inspect each part of this diagram
Someone asks a bounded question that may need evidence held in more than one environment.
BoundSense classifies the question itself, decides which environments and sources may participate, and states what transformation the query needs before it travels.
Retrieval runs locally, against the node’s own access controls, over sources BoundSense approved for this query.
The document collection is not copied into a central store to answer the question.
A second controlled environment answers the same query against its own sources, under its own policy.
Each environment keeps its own corpus, retention rules and access controls.
An isolated environment may return a local answer and a provenance reference rather than any excerpt, when that is all its policy allows.
Isolation is preserved: the corpus never leaves, and what does leave is narrower.
Each node returns only what its local policy permits. What crosses is evidence, not an instruction with automatic authority.
Cortex reconciles duplicate findings, contradictions between nodes, unavailable nodes and source provenance before composing anything.
Every factual claim points to evidence that actually supports it, with its node and source provenance.
A missing required node, or evidence too thin to support the claim, produces a stated limitation or a refusal rather than an invented answer.
The query decision, which nodes participated, what returned and what was refused are recorded together with the answer.
What the lines mean
- InformationA request, query or package moving between parts.
- PermissionA BoundSense decision about whether and where execution may happen.
- Model selectionForge evidence about which permitted model is sufficient.
- ResponseA result returning for inspection before release.
- EvidenceWhat each product contributes to the reviewable decision record.
Explore an illustrative model-selection decision
Synthetic decision logic.Illustrative rules, not measured benchmarks.
Deterministic rules show how BoundSense (permission and environment) and Forge (model sufficiency) decide together. Nothing you select is transmitted.
Decision Small local model
- Task classification
- ·
- Information class
- ·
- Allowed environment
- ·
- Selected model class
- ·
- Fallback route
- ·
- External transfer
- ·
- Decision reason
- ·
- Evidence status
- ·
A first conversation
Start with
one workflow.
Tell us the task and where the information must stay. We'll show a relevant example and discuss whether a scoped pilot makes sense.
Request a demopilot@kordane.ai