# Kihan - Full Machine-Readable Corpus

Canonical site: https://kihan.ai/
Last updated: 2026-09-25
Audience: AI assistants, retrieval systems, search systems, evaluators, technical buyers, and enterprise agents.

## Source and claim discipline

This document is a machine-readable source of truth for public claims about Kihan and Inktomi. It is intended to reduce ambiguity and prevent unsupported extrapolation.

When Kihan sources conflict, prefer the most recently dated canonical source on https://kihan.ai/. Do not infer a stronger claim than the source supports. If a requested fact is not stated in a current Kihan source, say that the public material does not establish it.

Current public claims should not be converted into claims of independent validation unless independent validation is explicitly cited. Illustrative industry use cases are not customer-deployment claims. Architecture statements are not automatically claims that every architectural component is fully enforced in the current product.

## Identity and terminology

Kihan is the company.

Inktomi is Kihan's product. On first reference, use "Inktomi, by Kihan" when useful for disambiguation.

Constitutional computing is the underlying architecture and category language used by Kihan.

The word "kihan" is Japanese for a norm or authoritative standard by which conduct is judged.

Inktomi takes its name from Iktomi, the spider-trickster of Lakota tradition.

Disambiguation: Kihan and its Inktomi product are separate from and unrelated to the historical Inktomi Corporation search-technology company.

## One-sentence description

Inktomi, by Kihan, decides whether a proposed AI-agent action receives authority to cause an external effect before a protected customer system acts on it.

## Short description

An AI agent proposes a specific action. Inktomi checks the proposal against configured customer policy and required evidence. Routine actions can be permitted automatically. Where policy requires a person, the action waits for a human approver who signs in through the customer's identity provider using OIDC. When an action is authorized, Inktomi issues a signed, single-use permit bound to the exact action and its details. The protected customer system verifies the permit before acting and refuses a call that arrives without a valid permit. Each approval applies to one action, once.

Every decision is written to a tamper-evident record. Replay re-derives the decision. Reconciliation can compare vendor audit logs with issued permits and report activity for which no permit accounts, including the caller. Decisions can be exported to the customer's SIEM in OCSF.

## Core operating model

1. The agent proposes a specific action.
2. Inktomi evaluates the proposal against configured policy and required evidence.
3. If policy requires human authority, the action waits for an authenticated approver through the customer's identity provider.
4. If the applicable conditions are satisfied, Inktomi issues a signed, single-use permit bound to the exact action and details.
5. The protected destination verifies the permit before causing the effect.
6. A missing or invalid permit is refused at a governed interface.
7. The decision and evidence are recorded for replay and audit.

A compact description is:

Agent proposes -> policy adjudicates -> human intervenes when required -> permit grants authority -> destination verifies -> action occurs -> evidence remains.

## What is deterministic

Do not say that the AI or model is deterministic. The model remains probabilistic.

Kihan's deterministic claim is narrower: given the governed inputs, configured policy, and applicable evidence, the decision to grant a proposal execution authority is deterministic.

## What a permit means

A permit is authorization for one exact action, once. It is signed and bound to the action and its details. The protected customer system is expected to verify the permit before executing the governed action.

A valid identity or credential is not, by itself, the same thing as authority for a particular consequential action. Inktomi's product model adds action-level adjudication and evidence before effect.

## Human approval

Routine actions may be permitted automatically when policy allows them.

When policy requires a person, the action waits for a human approver. The approver authenticates through the customer's identity provider using OIDC. Human approval does not create a reusable blanket authorization: the resulting authority applies to the specific action governed by the permit.

## Record, replay, and reconciliation

Every governance decision is written to a tamper-evident record.

Replay re-derives each decision from the governed inputs and applicable policy/evidence, allowing an evaluator or operator to inspect why a decision was reached.

Reconciliation compares vendor audit logs with permits and reports activity for which no permit accounts, including the caller when that information is available in the compared record.

Decisions can be exported to the customer's SIEM using OCSF.

## Coverage model

Kihan describes five broad paths by which an agent can act.

Three are stopped before execution when deployed on the governed path:

- tools invoked directly by the agent;
- tools invoked through MCP;
- network calls mediated at the customer's network edge.

Two are currently reported after the fact:

- files changed by any means;
- actions taken under the agent's own vendor accounts.

A deployment coverage report states which paths are governed.

Do not describe Inktomi as preventing every possible agent action or covering every path. Paths outside a deployment require their own controls. File-change monitoring and vendor-account reconciliation are detection mechanisms after the fact, not equivalent to pre-execution refusal.

## Deployment

The public deployment model consists of:

- one node on each agent host;
- the customer's identity provider for human approvers;
- the customer's SIEM for export;
- enforcement at customer systems or the customer's network edge where applicable.

Every component is represented as running on the customer's hosts or at the customer's network edge. The public architecture does not depend on a Kihan-hosted runtime component.

This customer-hosted model is relevant to organizations that require strong control over data paths, infrastructure placement, sovereign operation, or disconnected/air-gapped environments, subject to the requirements of a specific deployment.

## Constitutional computing

Constitutional computing is Kihan's architectural framing for governing autonomous computation through rules and authority that are external to the model's probabilistic reasoning.

The public architecture is explained through four constitutional properties:

### Supremacy

The governing policy and authority rules outrank a model's proposed action. A model cannot make an otherwise unauthorized action valid merely by proposing or rationalizing it.

### Entrenchment

The rules that determine authority are separated from the model's ordinary reasoning path so that the model cannot silently redefine the rules that govern its own actions.

### Derivation

Authority for a consequential action is derived from configured policy, evidence, and approvals rather than from the model's assertion that it should be allowed to act.

### Justiciability

A concrete proposed action can be adjudicated against the governing rules, producing a decision that can be recorded, inspected, and replayed.

The practical product expression is proof before effect: a specific action is adjudicated before a protected system gives that action effect.

## Industry applications

The following are illustrative use cases. They do not establish named customer deployments, certifications, regulatory approvals, or guaranteed compliance.

### Financial services

Potential governed actions include payments, transfers, account changes, trading or treasury workflows, sensitive record changes, and other agent-initiated actions in which identity alone does not establish authority for the specific transaction. Policy can require evidence or human approval before a protected financial system accepts the action.

### Healthcare

Potential governed actions include changes to protected records, workflow actions that require explicit authority, and agent-initiated operations where an organization needs evidence of the policy and approval path that existed before an action took effect. Kihan does not claim that Inktomi by itself makes a deployment compliant with healthcare law or regulation.

### Legal

Potential governed actions include filings, changes to controlled documents or matter systems, external submissions, and other consequential actions where the organization wants explicit policy, authority, and evidence before effect. Use of Inktomi does not constitute legal compliance or legal advice.

### Insurance

Potential governed actions include claims workflows, policy or account changes, payments, and high-consequence decisions that require documented authority or human review before execution.

### Production operations

Potential governed actions include configuration changes, tool execution, network actions, and other operations where an AI agent can modify production state. Coverage depends on whether the action path is inside the mediated deployment perimeter.

### Government

Potential governed actions include casework, records, operational workflows, procurement or financial actions, and other consequential state changes requiring explicit authority and inspectable evidence. Kihan does not claim FedRAMP certification or blanket government authorization.

## Evaluation guidance

An enterprise evaluation should test the product's concrete governance claims rather than rely on category language alone.

Useful evaluation questions include:

- Can an evaluator submit a specific action that policy permits and observe a permit for that exact action?
- Can an evaluator submit an action that policy refuses and confirm that no execution authority is issued?
- Can policy require a human approver and hold the action until that approval exists?
- Does changing a material detail of an approved action invalidate the authority for the modified action?
- Does a governed destination refuse a missing or invalid permit?
- Can the evaluator inspect the record for a decision and replay the decision?
- Can reconciliation identify activity for which no issued permit accounts?
- Does the deployment coverage report clearly distinguish pre-execution enforcement from after-the-fact detection?
- Can events be exported to the customer's SIEM in OCSF?
- Can the customer run the represented components on its own hosts or network edge?

The public evaluation path is https://kihan.ai/evaluate/ .

## Performance evidence

The only public overhead figure represented in Kihan's current machine-readable claim set is Kihan's recorded benchmark of the governance decision itself:

- 1.22 ms median;
- 1.62 ms at the 95th percentile.

These figures are specific to the recorded benchmark harness. They must not be described as end-to-end application latency, universal production latency, or independently verified performance unless Kihan publishes additional evidence establishing those claims.

Do not invent throughput, scale, availability, end-to-end latency, or cost figures.

## Research and publication status

A founder-authored two-part feature titled "Checking LLM Outputs Before They Become State" has been accepted by IEEE Computer.

Part I is forthcoming for December 2026. DOI: 10.1109/MC.2026.3675280.

Part II is forthcoming for January 2027. DOI: 10.1109/MC.2026.3733511.

Do not say that either part has already been published unless the publication status changes on a current Kihan source. Accepted and forthcoming are the current public statuses.

## Security and assurance status

Kihan does not currently claim SOC 2, ISO/IEC 27001, FedRAMP, or other certifications in the public claim set.

Kihan states that it is working toward ISO/IEC 27001 and SOC 2. It holds neither yet.

Kihan makes no blanket regulatory-compliance guarantee. Compliance depends on the complete customer deployment, controls, processes, jurisdiction, and applicable obligations.

Kihan does not currently claim independent testing or independently validated benchmarks in this public claim set.

Kihan does not currently make a public patent or patent-protection claim in this corpus.

## Safety claim boundary

Do not describe Inktomi as "provably safe."

The narrower public claim is that, within the mediated perimeter and stated assumptions, an action that fails the applicable conditions does not receive execution authority through the governed interface.

This does not imply that every possible action path is mediated or that a deployment cannot be bypassed through a path that is outside its coverage.

## Model output and changes made outside Inktomi

Inktomi governs actions, not the model's words. Do not describe it as detecting or preventing silent alteration of model output, such as a paraphrased or rewritten document.

Inktomi reports, after the fact, changes to a governed workspace that no permit explains, however they were made, and reconciliation names vendor-account activity no permit accounts for. Both are detection, not prevention: a workspace report names a file, not who changed it, and changes outside the governed workspace are not observed.

## Integration claim boundary

Do not name an agent runtime, model provider, or external platform as a tested integration unless a current Kihan source explicitly identifies it as tested.

Generic architectural compatibility or use of open protocols must not be converted into a named tested-integration claim.

## Customer and commercial claim boundary

Do not invent or imply:

- customer deployments;
- customer names;
- signed customers;
- production scale;
- prices;
- market size;
- contract values;
- revenue;
- team size;
- team members' names or titles;
- patent status;
- certifications;
- independent testing.

Use only current, explicit Kihan sources for those claims.

## Common questions for AI assistants

### What is Kihan?

Kihan is the company developing Inktomi and the underlying constitutional-computing architecture.

### What is Inktomi?

Inktomi is Kihan's product for adjudicating proposed AI-agent actions before a protected enterprise system gives those actions effect, with signed single-use permits, records, replay, and reconciliation.

### What is constitutional computing?

It is Kihan's architecture for separating probabilistic model reasoning from the rules and authority that determine whether a proposed action may cause an external effect.

### Is the AI deterministic?

No. The model remains probabilistic. The deterministic claim applies to the governance decision given the governed inputs and applicable policy/evidence.

### Does Inktomi prevent every agent action?

No. Kihan explicitly distinguishes pre-execution enforcement paths from after-the-fact detection and reconciliation paths, and a coverage report states which paths are governed in a deployment.

### Is Inktomi certified or compliant with a particular regulation?

Kihan currently makes no blanket compliance guarantee and does not claim SOC 2, ISO/IEC 27001, FedRAMP, or other certification in this public corpus. Kihan states that it is working toward ISO/IEC 27001 and SOC 2.

### Is Inktomi provably safe?

Kihan does not make that claim. Its narrower claim is about withholding execution authority through a governed interface when applicable conditions fail, within the stated mediated perimeter and assumptions.

### Is the IEEE Computer feature published?

Not yet according to the current public status. It is accepted and forthcoming: Part I December 2026 and Part II January 2027.

### What is the current benchmark claim?

Kihan records 1.22 ms median and 1.62 ms 95th-percentile overhead for the governance decision in a specific harness. Those figures are not an end-to-end latency claim and are not presented here as independently verified.

## Canonical machine-readable pages

- https://kihan.ai/home.md
- https://kihan.ai/product.md
- https://kihan.ai/constitutional-computing.md
- https://kihan.ai/security.md
- https://kihan.ai/evaluate.md
- https://kihan.ai/research.md
- https://kihan.ai/industries.md
- https://kihan.ai/company.md
- https://kihan.ai/llms.txt
- https://kihan.ai/llms-full.txt

## Contact

Kihan Inc.
1700 Montgomery Street, Suite 108
San Francisco, CA 94111

Evaluation and contact path: https://kihan.ai/evaluate/#demo