Our Technology

The technology under every KODA solution.

A hospital needs AI that behaves the same tomorrow as it does today, keeps its data where the hospital decides, and leaves a record of every step. This is the technology that does that, explained for the people who run hospitals.

A clinical team at a workstation, with the layers of the platform shown around them: workflow memory, roles and permissions, routing, edge operation and audit history

The principle

The model is not the agent.

Language models are powerful, and they change every year. What a hospital depends on must not change with them: who the system is acting for, what it may see, what it remembers, and who approved its work. We keep those in an operating layer, and use models as the work requires.

Six parts, one platform

What sits under the solutions

A monitor showing the KODA Kenkō operational layer between medical professionals above and existing medical systems below

01 · Operating layer

Kurahi runtime

The operating layer that keeps identity, memory, permissions, evidence and audit continuous while models change. Models think; Kurahi keeps everything around them whole, and keeps working between tasks when no model is running.

  • Permissions applied to the whole task, not just the final answer
  • Evidence tied to its source, date, version and permission
  • The full route recorded: models used, evidence retrieved, who approved

The model is not the agent.

A doctor, nurses and a manager working at two screens, one showing the patient record and one the operating layer

02 · Persistent agents

Agents that stay on duty

Long-running agents that keep their memory, role, policy and unresolved work across sessions and across model changes. The agent supporting your discharge team on Monday still knows on Thursday which cases were waiting for a result, what was agreed and who approved it.

  • A defined role and boundary for every agent
  • Delegation between agents is typed and attributable
  • Capability alone never grants authority

What a memory item carries

  • Source and date
  • Version and owner
  • Who may read it, and for what purpose
  • Which task used it, and when

03 · Memory

Memory persistence

Structured memory (facts, decisions, open tasks) and narrative memory (what happened, in order), each with its provenance. For every task the runtime retrieves the minimum authorised context, never the whole archive, and records which memory was used.

A model receives enough for the task, never the whole archive.

04 · Safety spine

Cross-model verification and human review

Every consequential draft is checked by a second, independent model that looks for unsupported statements, contradictions and anything outside the professional scope. Then the responsible professional reviews, corrects and approves it.

Only approved work becomes a record, with every reviewer, timestamp and change kept.

05 · Model choice

Models chosen by policy

Frequent and sensitive work, such as classification, extraction, routing and Japanese clinical documentation, can run on models inside your own environment. Broader models are used only where your policy allows it.

When a broader model is used, the runtime sends only the minimum authorised context and records that it did so.

A monitor in a hospital office showing how the operating layer connects professionals with the hospital’s systems

06 · Where it runs

Sovereign deployment

Data stays in the country: Japanese data in Japan, Brazilian data in Brazil. The deployment decides where data travels, and we state it plainly in each customer’s agreement.

  • On-premise — Models, memory, evidence and audit inside the hospital’s own infrastructure. External models can be switched off by policy.
  • National public cloud — Runtime and models in a dedicated environment in the country, controlled by the institution.
  • Hybrid — Routine and sensitive tasks stay local; approved tasks may use broader models with the minimum permitted context.

For your hospital

What this means for you

Not tied to one AI supplier

Models can be changed without changing how your teams work.

The same behaviour after an upgrade

Roles, permissions and records survive a change of model.

Your data stays where you decide

On your premises or on national public infrastructure.

Every answer can be explained

Which models, which evidence and which person approved.

What your IT team gets

  • Comes ready

    • The Kurahi runtime with policy, permissions and audit log
    • Cross-model verification before human review
    • Sourced memory with read permissions per item
  • Configured for you

    • On-premise, national cloud or hybrid deployment
    • Which models may be used, and for which tasks
    • Sign-in, roles and permissions from your directory
  • Who sets it up

    • Your IT lead provides the environment and network access
    • The KODA Kenkō team installs, connects and hands over
  • What your IT team learns

    • Reading the audit log of a task
    • Changing model and data policy safely
  • Scoped separately

    • Hardware for on-premise deployment
    • Integrations with systems outside the standard connectors

See how it would run in your hospital.

We will walk your IT and clinical leads through the deployment options, the controls and the record it keeps.

Our Technology — the operating layer under every KODA solution · KODA Kenkō