The core principle
Evodira is a knowledge-continuity platform, not a cloud search engine. Conventional enterprise search ingests and indexes your documents in a vendor cloud so it can rank them. Evodira does the opposite: it computes over a typed graph that links each claim to the evidence behind it, with an access-control list attached to the evidence and applied before anything is retrieved.
The practical consequence is specific. The documents, messages, tickets, and recordings that hold your sensitive content do not need to be uploaded anywhere in order to be useful. What moves is context: typed claims and the redacted quotes that support them.
Redaction before the model
An on-device local agent processes evidence where it already lives. It extracts and redacts on the device, before any model sees the content. What synchronises onward is claim-level knowledge and redacted quotes.
This ordering is the control. Redaction runs first, so the material a model processes is already minimised, and the original document stays on the device. Uploading raw source content is off by default and is a policy an administrator has to switch on deliberately for a given deployment profile; when it is off, there is no path that ships the file itself.
What leaves, and where it is processed
Claims and redacted quotes have to be embedded and synthesised into an answer, and that computation happens somewhere. In the default managed configuration it happens through a hosted model provider, today Google’s. The claim text and redacted quotes in a given answer are sent to that provider. Your raw files are not.
That routing is configuration, not architecture. Evodira can be pinned to a region-resident model endpoint, or pointed at a self-hosted open-weight model so nothing reaches a third party at all. On the device side the same boundary is enforced from policy: a deployment profile names which model providers the local agent may use, and whether cloud fallback is permitted at all. Cloud fallback is off by default, and a policy change that would disallow a running provider stops that provider rather than leaving it running.
We would rather state this plainly than let “private by architecture” imply that no model provider is ever involved. Ask us which configuration your pilot will run on and we will answer it in writing.
Where the data plane runs
Evodira ships as containers, and the deployment profile decides where the data plane sits. In the managed profile we operate both planes. In the hybrid profile, evidence, indexes, retrieval, and the local agent make up a data plane that runs on infrastructure you own, with a managed control plane for administration and policy. An on-premises installation runs the whole stack inside your boundary.
The honest qualification: hybrid and on-premises are installed with us, not self-served. We do not publish a Terraform module or a Helm chart today, and multi-region data residency is still being built. If your requirement is a specific jurisdiction, treat it as something to confirm with us during the pilot rather than as a switch already in the product.
Permissions travel with the evidence
Evidence carries an access-control list, and retrieval applies it first: inside the query, before anything is read, ranked, or synthesised. An answer is only ever assembled from evidence the person asking is entitled to see.
The part worth checking us on is the failure direction. Retrieval fails closed. Evidence that carries no ACL is quarantined and returned to nobody, rather than being treated as public-within-the-tenant. A permission bug in a ranked-search product shows someone too much; the same bug here shows them nothing.
Where each ACL comes from, precisely. Evidence captured by the local agent is always scoped to the person whose device it came from and to administrators. It is also readable by your whole workspace unless the extraction is marked confidential or higher. Since “internal” is the default, in practice most local evidence is workspace-readable. Marking a source confidential, restricted or secret keeps it to its owner and administrators. Evidence pushed through the authenticated ingestion API carries whatever permissions the caller supplies, and those are enforced unchanged. Evidence that arrives through that API without permissions is given an explicit installation-wide read grant and is visible to your workspace. That grant is scoped, recorded, and auditable, but it is not narrower than the workspace.
So we do not claim that every connector mirrors its source system’s permission model. No packaged connector does that yet. Mapping a specific system’s permissions onto the evidence it produces is work we do with you during onboarding, and until it is done for a given source, that source’s evidence is installation-scoped.
Two human gates
Nothing a model produces becomes authoritative on its own. Evodira has two points where a human is explicitly in control:
Gate one: the device. The local agent prepares a context pack as a draft; the person on the device approves it before it syncs. Two arrangements make that approval automatic, and we would rather name them than let the paragraph above imply a person always clicks: an installation running the agent in autonomous mode, and a managed deployment profile whose administrator has turned device review off for that fleet — intended for company machines nobody sits at, and only available where the workspace policy permits it. In both cases a pack records that a policy, not a person, stood behind it, and the desktop app says so on screen. Two further qualifications we would rather you heard from us: on a managed device an administrator can enable specific locations for indexing without prompting the person first, and a pack that trips the policy gate is held for review even in autonomous mode. Automation never widens what may leave the device; it can widen what gets looked at.
Gate two: verification. Extracted claims are routed to a human reviewer with their confidence score and sources attached. Knowledge becomes answerable only when a reviewer approves it, and certified only when a reviewer publishes it, under the approval rules your installation sets. Weak or contested claims can be returned, flagged, or rejected.
Verifiable provenance, not opaque scores
Each answer ships a tamper-evident certificate over the chain that produced it: the question, the model that answered, every claim cited, and the content hash of the exact evidence version behind each claim, folded into a single answer hash. You can recompute it offline and check that nothing moved.
Be precise about what that proves. The certificate attests the chain from claim to evidence: that this answer was built from these claims, and those claims from that evidence, unaltered. It does not attest the permission decision. Permissions are enforced before retrieval, as described in section 05, and recorded in the audit trail; they are not folded into the certificate hash. We would rather tell you where the artefact’s coverage ends than have your auditor find that edge for us.
Retention and deletion
Retention is set per installation, and today it is enforced on the device. The retention window in your deployment profile bounds how long the local agent keeps extracted content and its own audit events on the endpoint, and the agent deletes past that window on every cycle.
On the server side, evidence, claims, audit records, and certificates are kept rather than aged out. When a source is updated or contradicted, its history is preserved instead of silently overwritten, so the audit trail stays intact and a superseded claim can still be traced. There is no automatic server-side purge job yet, so deletion and export are operations performed against the data plane rather than a setting that expires content for you. We will document the exact mechanics for your deployment profile during onboarding.
What we are honest about
Evodira is an early-stage product. Evodira is built for SOC 2 and GDPR from the architecture up, with data residency, redaction, audit trails, and human approval gates as first-class controls. The EU AI Act’s transparency and general-purpose obligations have applied since 2 August 2026, and we work to them as current law rather than as a date ahead of us. These statements describe our posture and design. They are not certifications we have completed. We will share the current state of our documentation, controls, and any attestations directly with you during a security review or pilot.
Questions about any of this? Write to us at hello@evodira.com. We will share current documentation and attestations during a pilot.