Menu

Request a demoStart using OIDA

OIDA for developers

Governed memory for agents, via MCP.

A remote MCP server (Streamable HTTP, OAuth 2.1 + PKCE) that answers resolve_decision_state with the current decision, scope, evidence and state: verified, contested, insufficient_evidence, unknown. Deterministic resolver, no server-side LLM.

Start using OIDA Request a demo

Five questions your agent cannot settle today.

These are not retrieval questions. They are questions of state: which ADR is in force, for which environment, since when and whether anyone has decided. Here is what OIDA returns.

Illustrative examples. Choose a question and compare the answer and sources.

Get a demo

assistant · connected to OIDA

Which authentication library is the standard for new services?

  1. resolve_decision_statescope new services
  2. Reading the sources in the registryADR-042 · Security review, Jan 2026
  3. State resolvedIn force

auth-core v3 is the standard authentication library for new services.

In force · scope new services · from 10 Feb 2026 · supersedes ADR-017, Passport

auth-core v3. Source: ADR-042, February 2026. ADR-017 (Passport) is superseded.

Sources
  • ADR-042New services use auth-core v3 for authentication and sessions. ADR-017 (Passport) is superseded.Primary
  • Security review, Jan 2026Evidence

The solution

A shared memory that grows as your company grows, and builds your own intelligence, for full sovereignty over your data.

Search finds every version. OIDA identifies the one in force.

A person asks the assistant they already use. The answer includes state, scope and evidence.

assistant · connected to OIDA
Your AI assistant · AI modelShare

Which database is approved for new services?

oida · resolve_decision_state

Resolving the database topic, scope: new services

Contested

PostgreSQL is the approved database for new services.

ADR 024 · scope: new services · from 1 Feb 2026 · contested while a conflict remains open

PostgreSQL, under ADR 024, in force since 1 February 2026 for new services. An open conflict concerns this decision: a chat message proposes DynamoDB. It is recorded, not approved.

oida · platformOpen in OIDA
Decision registrytopic database
  1. In force
    PostgreSQL is the approved database for new services.ADR 024 · scope: new services · from 1 Feb 2026 · contested while the conflict below remains open
  2. Superseded
    MySQL is the default database.ADR 001 · superseded by ADR 024 · kept as history, never returned as current
  3. Scoped exception
    MongoDB remains approved for legacy services.ADR 011 · scope: legacy · returned only for that scope
  4. Open conflict
    “We are moving new services to DynamoDB.”Team chat, 14 Mar 2026 · non-authoritative · recorded, not applied · awaiting review
  5. Unknown
    Where do we store the mobile app’s data?No approved decision · nothing inferred

Three moments when the registry speaks your language.

  1. 01

    Onboarding to a repository

    On day one, the agent asks OIDA which ADRs are current for your service, which are superseded and which exceptions apply to that module. Context arrives as state, with supporting excerpts, before opening the first file.

  2. 02

    An agent writing a runbook

    Before writing, the agent calls resolve_decision_state for every decision the draft depends on. Exceptions stay within their scope. Open conflicts go into a reviewer note. Nothing is applied just because it is the latest chat message.

  3. 03

    Reviewing a decision made at stand-up

    A developer records it from the client using ingest: it enters as a proposal with a source and excerpt. An owner or admin approves it, rejects it or uses it to supersede a previous decision, with a reason that stays in history.

State, decision, scope, evidence and conflicts in one object.

The actual shape of a resolve_decision_state response, taken from the server code (src/tools/resolve-decision-state). Values are illustrative, using the showcase’s database topic. The fields are real.

{
  "query": "Which database is approved for new services?",
  "topic": "database",
  "status": "contested",
  "decision": {
    "id": "adr-024",
    "content": "PostgreSQL is the approved database for new services.",
    "value": "PostgreSQL",
    "status": "approved",
    "scope": "new-services",
    "valid_from": "2026-02-01",
    "valid_to": null,
    "confidence": 0.95,
    "authority": 1
  },
  "scope": "new-services",
  "temporal_validity": {
    "as_of": "2026-09-08",
    "valid_from": "2026-02-01",
    "valid_to": null
  },
  "sources": [
    {
      "source_id": "adr-024",
      "title": "ADR 024",
      "type": "decision-record",
      "reference": "docs/adr/024.md",
      "occurred_at": "2026-02-01"
    },
    {
      "source_id": "adr-001",
      "title": "ADR 001",
      "type": "decision-record",
      "reference": "docs/adr/001.md",
      "occurred_at": "2023-05-12"
    },
    {
      "source_id": "adr-011",
      "title": "ADR 011",
      "type": "decision-record",
      "reference": "docs/adr/011.md",
      "occurred_at": "2024-09-03"
    },
    {
      "source_id": "team-chat-2026-03-14",
      "title": "Team chat",
      "type": "team-chat",
      "reference": "#platform",
      "occurred_at": "2026-03-14"
    }
  ],
  "evidence": [
    {
      "source_id": "adr-024",
      "excerpt": "PostgreSQL is the approved database for new services from 1 February 2026.",
      "verified": true
    }
  ],
  "superseded_decisions": [
    {
      "id": "adr-001",
      "content": "MySQL is the default database.",
      "value": "MySQL",
      "status": "superseded",
      "scope": "all",
      "valid_from": "2023-05-12",
      "valid_to": "2026-02-01",
      "confidence": 0.9,
      "authority": 1
    }
  ],
  "scope_exceptions": [
    {
      "id": "adr-011",
      "content": "MongoDB remains approved for legacy services.",
      "value": "MongoDB",
      "status": "approved",
      "scope": "legacy",
      "valid_from": "2024-09-03",
      "valid_to": null,
      "confidence": 0.9,
      "authority": 1
    }
  ],
  "conflicts": [
    {
      "conflict_id": "rel-dynamodb-vs-adr-024",
      "item": {
        "id": "claim-chat-dynamodb",
        "content": "We are moving new services to DynamoDB.",
        "value": "DynamoDB",
        "status": "proposed",
        "scope": "new-services",
        "valid_from": "2026-03-14",
        "valid_to": null,
        "confidence": 0.6,
        "authority": 0.3
      },
      "source_ids": [
        "team-chat-2026-03-14"
      ],
      "rationale": "Incompatible database choice for the same scope.",
      "status": "open"
    }
  ],
  "missing_information": [
    "At least one incompatible claim remains unresolved."
  ],
  "context_metrics": {
    "source_characters": 18420,
    "evidence_characters_returned": 78
  },
  "drill_down": {
    "required": false,
    "suggested_tool": null,
    "reason": "Current state, supersessions, scoped exceptions, conflicts, evidence, and sources are already included. Use a drill-down tool only if the user explicitly asks for exhaustive history or conflict remediation."
  }
}
status
One of four values: verified, contested, insufficient_evidence, unknown. Here, contested: a current decision exists and an incompatible claim remains open in the same scope. verified is a registry application state, neither a signature nor certainty that the decision is right.
decision
The selected decision: ID, statement, value, scope, validity period, confidence and authority. It may be present even with insufficient_evidence: always check status and missing_information before using it. null when no decision can be selected.
scope
The scope for which the question was resolved. If you do not supply it, it is the scope of the decision found.
temporal_validity
as_of selects the effective date, today when omitted. Current revocations and conflict resolutions also apply to past dates; it does not reconstruct what was known then.
sources, evidence
sources lists sources for the decision, superseded decisions, exceptions and conflicts. evidence carries excerpts, with verified true when the excerpt has been checked against the source text. Never the whole document.
superseded_decisions
Decisions that the current one superseded. They remain in history and in the response, with their valid_to, never returned as current.
scope_exceptions
Current decisions in a scope that does not overlap the resolved one: here, MongoDB for legacy. The client knows they exist and where they apply.
conflicts, missing_information
Claims incompatible with the decision, with the relationship ID, sources and rationale. While one remains open, the state is contested and missing_information says so explicitly.
context_metrics, drill_down
context_metrics compares source characters with the characters in returned excerpts. drill_down says whether another tool (get_decision_history, find_conflicts) is needed or this response is enough.

Keep your repository documentation free of contradictions.

A Claude Code plugin that analyses claims in a repository’s Markdown files and comments and shows where they contradict each other. You review each finding on a local graph, approve or dismiss it, and the agent applies approved corrections.

  • Finds contradictions, supersessions and duplicates between claims in different files.
  • Flags questions the repository has already answered, orphan documents and links to superseded material.
  • Distinguishes binding from provisional claims by convention, using file paths and names, and dates each claim from Git.
  • Human review on a local graph: approve, keep the tension or dismiss, with a note.
  • Applies only what you approve, one agent per file, with verification of changes.
  • Never commits. You review the diff.

What it adds is not better contradiction detection but a materialised state layer: which claim is binding, which was withdrawn and by what, which question is still open, dated per claim from Git.

OIDA for Code on GitHub 

/plugin marketplace add Project-OIDA/oida-for-code
/plugin install oida-for-code@oida-tools
/oida-for-code:scan [path]
/oida-for-code:structure [path]

Claude Code with plugin support, Git, python3 (standard library only). MIT licence.

Search brings every version. OIDA brings the state.

Same model, same question. What changes is what enters the context window before the model answers.

With search

  • The passages most similar to the question, from every document version.
  • The current ADR and the superseded ADR as equivalent text.
  • An exception without its scope: the model has to guess where it applies.
  • The latest chat message carries as much weight as the approved decision.
  • A silent registry is indistinguishable from a document not found.

With OIDA

  • A state: verified, contested, insufficient_evidence or unknown.
  • The current decision, with its scope and validity period.
  • Superseded decisions as history, with the date they stopped applying.
  • Exceptions with their scope. Open conflicts with sources and rationale.
  • The excerpts supporting the answer, never the whole document.

From recurring patterns to an adapter you mount yourself.

The memory says what is in force now, and changes when the decision changes. An adapter changes something else: the model’s tendency to answer in a certain way. You do not train a model from scratch, you extract the patterns that matter from the dataset and compress them into a few weights.

Volume is not the value: what is needed is signal, context, question, answer, scope, outcome and the correction when it came. That is already the shape the memory keeps them in, which is why no separate collection project is needed.

Illustrative example of the same question, before and after the adapter.

Which architecture do we choose for this new service?

Base model only

It depends on the requirements. You could use microservices, a modular monolith, serverless or an event-driven architecture: each has advantages and drawbacks to weigh in your context.

  • A different structure every time
  • Trade-offs listed, not weighed
  • No decision, and no criterion for taking one

Base model + adapter

Context
new service, small team, fast delivery.
Trade-off
today distributed complexity costs more than the value it brings.
Decision
modular monolith, explicit domain boundaries, a documented path to extraction.
When it is reviewed
at the agreed operational threshold, not before.
  • The same format every time
  • The same principles, applied
  • Ends with a decision

The memory brings the rules in force. The adapter brings the shape of the answer. Both are needed: current state plus learned behaviour.

Today OIDA Cloud stores and does not train. The OIDA Intelligence pipeline is implemented and tested in a separate codebase, is not connected to Cloud and is off by default. If your organisation used it, training would start only from a dataset an owner had admitted under recorded rules, and a candidate would be compared with a baseline before an owner decided on promotion.

Read the documentation

Lost time has a cost. Measure what changes for your team.

More than 6 in 10 times

when the document the AI retrieves holds a wrong figure, the AI repeats it as true: even when it knew the right answer

ClashEval, 2024–2025: six models compared on over 1,200 questions across six fields

50 hours a month

spent reconstructing decisions if ten people spend fifteen minutes a day

Making fewer mistakes, and managing your ontology and your company memory to build an AI of your own, means saving money.

Find the decision

Ask which rule applies today and read the source alongside the answer.

Your AI assistant

QuestionWhich database do we use for a new service?

Toolresolve_decision_state

OIDAone answer, with its source
In force

PostgreSQL is the approved database for new services.

ADR 024 · scope new-services · since 1 Feb 2026

  • ADR 024 · Choice of databaseNew services use PostgreSQL.primary

Architecture and sovereignty

Your decisions stay with you, even when you change AI.

Decisions stay in a registry separate from the AI model. In Cloud, data is in the database we run and each organisation has its own workspace. For enterprise integration we talk directly to your IT department and keep your data in your own infrastructure, with your own policy.

Your AI assistantscompatible, via MCP

Your peopleweb app

Who asksyour people and your tools

OIDAthe decision layer
  • explicit rules for decision state
  • traceable sources and evidence
  • recorded authority and scope

  • No copy of your documentsOIDA stores the source text you submit, decisions and evidence. MCP answers return excerpts and references.

  • No trainingOIDA trains no model on the data in the registry. The dataset stays yours: any use starts from a decision of yours.

Your databasewhere the decisions stay

Cloudone workspace per organisation, data kept separate, Frankfurt

Enterprise integrationyour infrastructure and your policy, agreed with your IT department

Your data stays where you decideOriginals stay in their systems; OIDA retains submitted sources.

The model is the tenant. The structure is yours.

Data sovereignty starts with where data is stored and who can access it: we define those boundaries together for the pilot. AI sovereignty starts with a memory separate from the model, queryable through MCP, the protocol that connects assistants to external tools. You can change compatible assistants while keeping the same registry.

95 %or more of respondents consider private and sovereign AI important. 29% concretely prioritise sovereign AI in the near term
NTT DATA, 2026 Global AI Report, nearly 5,000 senior decision-makers across 30+ markets

  • Boundaries. Where the registry lives and who may read it is your call, settled before the pilot starts.

  • Models. Authorised assistants query the same registry, kept separate from models.

  • Permissions. Access by workspace, actions by role. Applicability scope is not a reading permission.

  • Efficiency. Answers carry excerpts, state and references. Use the pilot to assess the context your agent needs.

Accelerated in Turin, with a scientific advisor from MIT.

OIDA is accelerated within Kakashi Venture Accelerator, an AI-native venture studio based in Turin, with senior scientific advisor Pierfrancesco Beneventano, researcher in machine learning theory at Massachusetts Institute of Technology. The method is described in a publication with public evaluation corpora.

We publish what we learn.

All publications

Works with the clients you already have.

Connect a compatible client and authorise workspace access. Your agent can query decisions, sources and states through MCP. Another authorised AI client can consult the same registry.

Connect your AI

  • ChatGPTin developer mode
  • Claudeweb, desktop and mobile
  • Claude Code
  • Cursor
  • CodexCLI and IDE extension
  • GitHub Copilotin VS Code
  • Any MCP client

Get started with a clear approach.

  1. 01

    Documentation

    How to connect a client, what an answer contains, who approves what and where data lives.

    Read the documentation
  2. 02

    Research

    The method behind OIDA and other publications, with public evaluation corpora.

    All publications
  3. 03

    Installation guide

    Setup steps and workspace address for each compatible client, inside the web app.

    Open the guide

Frequently asked questions.

How to start, who approves, who can read, and what works today.

Can I use it locally?

Yes. OIDA Local is a TypeScript process, a SQLite file and an MCP server over STDIO, for one operator on their own machine. It is not a multi-user deployment: a team needs OIDA Cloud or the integration service on your database.

Which clients have been tested?

Claude Code, Cursor and Codex have completed a real end-to-end run. ChatGPT in developer mode, the Claude apps and GitHub Copilot in VS Code are documented and follow the vendor’s published setup path. Any client supporting Streamable HTTP and OAuth 2.1 can connect. Clients that send only a static header cannot.

Is it open source?

OIDA for Code is open source under the MIT licence on GitHub. OIDA Cloud’s code is MIT-licensed, but the repository is not yet public.

Is OIDA an assistant or a chat?

OIDA is a decision registry your AI assistant can query. Keep working in your existing compatible client. You record the relevant sources: OIDA does not automatically listen to calls or conversations.

Who approves a decision?

By default, owners and admins approve. Member contributions stay proposed. An owner can enable peer governance, allowing members to approve decisions too. Inferences from prose stay proposed. Ontology changes always require separate approval by an owner or admin.

Does OIDA train models on our data?

OIDA Cloud stores decisions, evidence and history without training models. OIDA Intelligence is a separate pipeline, not connected to Cloud and off by default. Using it requires an owner-admitted dataset, recorded rules and evaluation before a candidate model is approved.

Which clients work today?

Claude Code, Cursor and Codex have completed a real end-to-end run. ChatGPT in developer mode, the Claude apps and GitHub Copilot in VS Code follow the vendor’s published setup path. Any client supporting Streamable HTTP and OAuth 2.1 can connect. Clients that send only a static header cannot.

How much does it cost?

OIDA Cloud is in pilot. Request a demo to agree on the use case, access and pilot terms.

Start with one decision. Check what your AI answers.

Choose a decision that changed recently: an offer, a procedure or a policy. Bring the earlier source and the approved one.

  1. 01

    Create your workspace

    Sign up with your email and organisation name. Confirm your email when requested and sign in to your workspace.

  2. 02

    Connect your assistant

    Follow the installation guide: copy OIDA’s address into a compatible assistant’s settings and authorise access.

  3. 03

    Record, approve, check

    Ask your assistant to propose a map of topics and scopes, then approve it. Record the decision with its source, approve it and ask what applies now.

Start using OIDA

Start using OIDA Request a demo