The connected operating layer.

What the Advanced Edition adds

The local edition demonstrates the operating model at individual scale. Its approvals are instructions to an agent. Its cadence runs when you start a session. The Advanced Edition keeps every Markdown contract — the pipeline, the evidenced memory schema, the wiki rule, skills as documents — and adds five things so those promises become behavior you can verify.

• 01 · Runtime

  It runs on a cadence without being asked.

  A local-first runtime operates on your Markdown vault. A desktop daemon first. A self-hosted always-on node later. The same vault contracts at every stage.

  Private-launch capability

• 02 · Connectors

  Authorized sources, least-privilege scopes.

  Connectors to mail, calendar, documents, CRM, and research feeds use the Model Context Protocol. Each source has its own scopes, filters, and a contract you can read.

  Private-launch capability

• 03 · Action gateway

  Approvals enforced in code.

  One component holds write credentials. Agents never do. A consequential action reaches the outside world only through the gateway, and only with your recorded approval.

  Private-launch capability

• 04 · Specialist agents

  Bounded, steerable, stoppable.

  Research, briefing, communications drafting, and follow-up agents work with limited tools and isolated context. Each returns a structured handoff for review.

  Product direction

• 05 · Learning loop

  Skills change only through validation and approval.

  Operational patterns feed one atomic skill proposal at a time. Each must pass your example cases with no regressions. Nothing goes live without your approval.

  Concept workflow

How to read the labels on this page

Private-launch capability

In scope for the first cohort. Designed and specified. Not shipped.

Product direction

Planned for a later stage of this edition. Sequenced after the first cohort.

Concept workflow

A proposed mechanism that still has to earn trust through testing before it is switched on.

Design principle

A rule the design holds itself to at every stage.

Who it is designed forProduct direction

One executive and their chief of staff, first. It reads only the sources you authorize. It briefs you on your cadence with every item cited. It delegates bounded work to specialist agents. It cannot send, share, or commit anything without your approval.

Executive or founder

Wants to start the day with what changed, what is due, and what stalled, and wants decisions to stay decided. Needs connectors and an unattended cadence. Will not run agent sessions by hand.

Chief of staff

Needs to review everything the system now touches. The edition gives a review surface, audit history, and, in a later stage, delegated approval for named action classes.

Small leadership team

A later stage. A shared decision register and commitments across people, with a role model, private and shared memory spaces, and organization-level audit.

Not the right fit at first: regulated financial institutions, the public sector, and any organization that requires certifications Ækora does not hold.

Local edition and Advanced Edition

Two editions, one operating model. The Advanced Edition is the local edition’s upgrade path, not a different product.

Architecture in plain languagePrivate-launch capability

Everything runs on your device or your own node, against a Git-backed Markdown vault that remains the source of truth. Reading and writing are separate paths with separate credentials. That separation is the central idea.

Why the gate holds

Agents have no write tools

Agents can read through scoped proxies and can propose. Write tools are not registered for them at all. A fully compromised agent process still has no write token to use.

The gateway never calls a model

It verifies and executes. Injected text cannot reason it into acting.

An approval covers one exact payload

Recipients, body, attachments, attendees. The approval is bound to a hash of that payload. Any edit after approval requires a new approval.

Reconciliation checks the claim

A daily job compares the provider's sent items and calendar changes against the gateway's log. An unmatched outbound item is treated as an incident. Actions you take yourself in the provider's own interface are labeled as yours.

The harness hook is a second layer

A pre-tool check blocks and logs attempts. Approval safety does not depend on it. Credential separation is the primary control.

Where it runs

Desktop daemon Private-launch capability

A signed macOS app runs the agents, connectors, gateway, and scheduler against your local vault, with your own model keys. Closest to the local edition. The honest limit: cadence needs the machine awake, and there are no mobile approvals.

Self-hosted node Product direction

The same runtime as a container or VM in your cloud or on your premises, synced through your own Git remote. Always-on cadence and team-ready. You control the location. You also carry the operations.

Managed single-tenant, EU Concept workflow

Undecided. Considered only if customers ask for it and the compliance work it requires is funded and done first.

Connectors and the permission modelPrivate-launch capability

Connectors use the Model Context Protocol, an open standard. Nothing is connected implicitly. Read tokens live in the read proxies. Write-capable tokens live only in the gateway. IEVA runs pinned, reviewed connector builds and sets policy from its own files. A connector’s description of its own tools is never trusted for policy.

A permissions panel that reads like a contract

Each source has a connector contract: a Markdown file in your vault with scopes, filters, retention, and the policy for every action. The plain-language summary is generated from the settings and must match them. Every change is a Git commit and an action-log event.

Derive and point. Do not hoard.

IEVA does not bulk-copy your mailbox. Read proxies return items with stable identifiers and cache excerpts only as long as your retention rule allows. Derived context carries links back to its sources. Hidden or instruction-like content is stripped or flagged, and the flag follows everything derived from that item.

Action classes

Approval routingPrivate-launch capability

A proposed action is stored as data: payload, rationale, sources, taint flags, action class, requesting agent, expiry. It waits. The approval surface shows you a card and signs your decision. The gateway checks the signature, the payload hash, the expiry, and the policy, then executes exactly what you approved.

What an approval card shows

• The action, its class, and whether it can be undone.
• The exact recipients or attendees. New external domains are highlighted.
• The full payload, with a diff against the last draft you saw.
• The sources used, as openable citations.
• A taint flag when external content shaped the action.
• The requesting agent, its objective, and the skill versions in use.
• Approve, edit, or reject. A rejection reason feeds learning. Nothing approves itself on a timeout.

Delegated approval Product direction

In the self-hosted stage, you can delegate named action classes on named connectors to a chief of staff, with constraints such as internal domains only. Irreversible actions to new external domains still require you, unless you explicitly edit that rule. That edit is itself a material change and needs confirmation.

Permission-aware memoryPrivate-launch capability

The local edition’s memory record is kept: statement, evidence type, source, date, review condition, sensitivity, confidence. The Advanced Edition extends it, so a local vault migrates cleanly.

Sensitivity

Four levels: public, internal, confidential, restricted.

Visible to

Owner by default. Optionally the chief of staff or a named team. Enforced when context is assembled for an agent or another person.

About persons

Links an entry to the people it concerns, so everything about a person can be found when someone asks to see it or remove it.

Retention

Until a date, while the source exists, or reviewed yearly. A daily sweep applies the rule and produces a deletion or a review task.

Derived from

Provenance links to the source items an entry came from. Citations resolve at view time and say so when a source is gone.

Learning use

Allowed or excluded. Excluded material never enters the learning loop.

Restricted entries

Restricted entries are not written to Git. The Markdown file holds a stub. The content is designed to live in a separate encrypted local store, viewable in the console. Special-category personal data is never inferred and never stored by default.

Decisions need you

An outside email can create only an observed candidate. A decision enters the register when you confirm it. Your explicit correction always outranks observation and inference.

Deletion propagates

Delete a memory entry, a source item, a person, or a connector, and the request follows provenance links through everything derived from it.

1. Delete requestEntry, source item, person, or connector
2. Provenance closureEverything derived from it is found
3. Memory and briefingsDeleted or redacted, with a dated note
4. Traces and restricted storeKeys destroyed, content unrecoverable
5. Patterns and casesReferences removed. Unsupported patterns retired.
6. TombstoneIdentifiers and hashes in the log. No content.

An honest caveat. Git preserves history. The design keeps restricted content and traces out of Git, and keeps confidential entries short. Where deleted content did enter Git history, IEVA offers a history rewrite. It is destructive, and it requires your explicit approval.

Specialist agents and cadence

Each agent is a versioned file: pinned skills, an allowlist of tools, an egress allowlist, a data scope, and a budget. The orchestrator may never grant an agent more than its definition.

• Agent · Briefing

  Assembles cadence briefings with citations.

  Can read

  Authorized sources (filtered), memory visible to you, projects.

  Can propose

  The briefing file. An internal write.

  Cannot

  Take any external action. Fetch from the web.

  Private-launch capability

• Agent · Research

  Produces cited briefs from public sources.

  Can read

  Research feeds, an allowlist of sites, public sources.

  Can propose

  A handoff with claim-level citations.

  Cannot

  Read private connector data. Untrusted content, private data, and a way out never meet in one agent.

  Private-launch capability

• Agent · Communications drafting

  Drafts in your voice, grounded in recorded decisions.

  Can read

  The thread in scope, your communication profile, linked decisions.

  Can propose

  A draft, and a proposal to send. Both gated.

  Cannot

  Browse the web. Read unrelated mailboxes. Keep remote images or tracking links in a draft.

  Product direction

• Agent · Delegation follow-up

  Tracks commitments and handoffs. Drafts nudges.

  Can read

  Commitments, open loops, the handoff board.

  Can propose

  Reminder drafts. Internal loop status updates.

  Cannot

  Send without approval.

  Product direction

The delegation lifecycle

1. FrameObjective, definition of done, tools, prohibitions
2. RunIsolated context. Status, time, and tools on the board.
3. Steer or stopStopping records a partial handoff
4. HandoffClaim-level citations. Ready for review.
5. ReviewAccept, revise, or discard

Delegated findings never become memory, output, wiki, or external action automatically. Promoting a finding to memory is its own approval.

Scheduled cadence, with honest failure Private-launch capability

The scheduler runs only the jobs in a cadence file you approved: morning briefings, weekly review preparation, the nightly learning pass. Each briefing item says what needs attention, why it matters, where it came from, and what action is available.

• A missed run is reported as missed. It is never backfilled silently. A catch-up run is labeled late.
• A connector error shows as an error in that section of the briefing.
• Nothing to report reads “no material changes”. No padding.
• “IEVA, step back” pauses proactive work and inferred learning. Briefings you scheduled explicitly continue until you pause them too.

The full learning loopConcept workflow

IEVA’s skills improve only through validated, approved changes. The loop adapts the WikiSkill approach to governed skill evolution: learn from traces, propose one small change, test it against cases, and keep a person at the release gate.

Five layers, kept separate

When the maintainer finds a fact about your world rather than a procedure — say, that you prefer two-line summaries — it routes that as a memory proposal, not a pattern.

The loop

1. CaptureTraces with outcome signals: approved, edited, rejected, corrected
2. MaintainNightly: root causes become patterns. Stale patterns are pruned.
3. ProposeOne atomic change: create, patch, or no action
4. ValidateHeld-out example cases, repeated paired runs
5. You approveDiff, results, spot-checks, cost. Then it goes live.
6. Monitor and roll backOne action reverts to the last approved version
7. LedgerEvery proposal recorded, accepted or rejected

Example cases come from your own signals

A correction becomes a protected regression case. A draft you approved becomes a golden case. A rejection with a reason becomes a negative case. Injection red-team items ship as protected security cases. A candidate case joins a suite only after you approve it, and synthetic paraphrases are recommended over real data for confidential sources.

The validation gate

The candidate skill is built on a Git branch and replayed against recorded fixtures, several paired runs per case, next to the live version. Deterministic checks run first. Then a blinded, position-swapped pairwise judge scores against a rubric. You spot-check a sample of its judgments. Where the judge and people disagree too often, that rubric becomes human-only until recalibrated.

01 — Lint passes

No edits to protected sections. No new tools, domains, recipients, or permission text. Approval rules, privacy boundaries, and prohibited actions cannot be changed by the loop.

02 — No new deterministic failures

On any held-out case, across repeated runs. Citations resolve, no outbound calls, format holds, recipients match.

03 — No protected case regresses

Cases created from your corrections are protected. A correction must stick.

04 — The target cases improve

The change must fix what it claims to fix, in most repeated runs, where the live version did not.

05 — Non-negative paired balance

On the remaining held-out cases, wins must at least match losses. This guards against silent erosion.

06 — A statistical check for wider changes

New skills and multi-section patches need a paired significance check in the candidate's favor, or an explicit override recorded as accepted without statistical support.

07 — Cost holds

Tokens per run must not rise materially unless you accept the increase.

Passing the gate does not make a skill live. It makes the proposal eligible for your approval. When a suite holds too few held-out cases, the report marks the result low-evidence and recommends deferring.

Overnight evolution, morning review

One iteration per night, under a budget cap you set, at most one proposal. The morning report lands in your vault: what IEVA looked at, what changed in the pattern base, the proposal with its diff and results, judge decisions to confirm, and new cases awaiting approval. You can approve, approve in shadow, reject with a reason, or defer. The report always states that nothing in the live skills was changed.

Rollback, ledger, and model changes

• Rollback. One action reverts a skill to its last approved version. An automatic revert when post-release corrections spike is proposed for the self-hosted stage. It restores a state you already approved, so it creates no new authority.
• Skill-impact ledger. Append-only. Every proposal, its diff, its results, and the decision. Rejected ideas stay visible in full so they are not proposed again.
• Model transfer. Each skill records the models it was validated on. A model change re-runs the gate on the new model. Model-specific workarounds are tagged and not transferred by default.
• Separation. Executing agents never receive the pattern base. They get their pinned skills and scoped memory, nothing else.

First-cohort behavior: propose-only. Proposals and gate results are shown, and nothing is accepted, until the gate has been calibrated against human judgment. That calibration is an entry condition for the next stage.

Audit and provenancePrivate-launch capability

Three layers, so the history of what the system believed and did accumulates as a side effect of normal operation.

The chief-of-staff review, answered in the console

What the system believes

A memory browser by decisions, commitments, people, and open loops, filtered by sensitivity and evidence type.

Where it came from

A citation resolver and provenance view for any item.

What ran

A job and agent timeline.

What went out

Executions joined to their approvals and reconciliation status.

What is pending

The approval queue, handoffs, and commitments by age.

What was corrected

The corrections log, memory history, and the regression cases that resulted.

What IEVA learned

Pattern changes, proposals, gate results, and skill versions.

Security and compliance postureDesign principle

The threat model assumes that content arriving through connectors is hostile, that agents can be manipulated, and that approval can become a reflex. The controls below are design commitments. None has been verified in a shipped system yet.

Secrets

• No secrets in Markdown.
• Connector tokens and model keys are kept in the operating system’s keychain on the desktop, or a secret manager on the node.
• Tokens are revoked when a connector is disconnected.
• Logs are redacted before they are written.

Data handling

• The runtime and your vault stay on your device or your infrastructure in the desktop and self-hosted stages.
• Model calls leave the device. “Local-first” is not a data-residency claim. Each connector carries a flag for whether its content may be sent to your model provider.
• Mail, calendars, and relationship memory contain other people’s data. The design supports you with per-person indexing, export, deletion propagation, and short default retention for cached excerpts and traces.
• Special categories of personal data are never inferred and never stored by default.

What we will provide, and what we will not claim

For customers with supplier-security expectations, the plan includes a security questionnaire pack, an incident response commitment, exportable audit logs, and a vulnerability disclosure address. These are planned, not published.

We make no claims of SOC 2, ISO 27001, GDPR certification, specific encryption implementations, or data-residency guarantees. Sandboxed execution at platform scale stays planned until it is implemented and tested. A control moves to verified on the security and governance page only when a test artifact stands behind it.

A staged roadmap, honestly labeled

Stages, not dates. Each stage has criteria it must demonstrate before the next begins. The criteria are targets we intend to hold ourselves to. They are not results.

1. Stage 0 · Foundations

   Contracts before connectors. Product direction

   The local edition's contracts become the base the runtime stands on. This stage overlaps the local edition's release.

   In scope

   • Git in every vault, one memory schema, versioned skills with a stated purpose.
   • A spike that demonstrates the three harness interfaces the gateway design relies on.
   • Discovery conversations with executives and chiefs of staff.

   Must demonstrate

   • The health check passes on a vault with every contract populated.
   • Session log, headless run, and pre-tool interception shown working on one model.

2. Stage 1 · Alpha · first cohort

   A desktop daemon for a small cohort of executives. Private-launch capability

   A signed macOS runtime on your own vault, with your own model keys. One ecosystem only: Google Workspace or Microsoft 365. High-touch onboarding. The learning loop runs in propose-only mode.

   In scope

   • Mail read and draft, calendar read, documents read with folder filters.
   • The action gateway, with approvals for sending and calendar invites.
   • Briefing and research agents. A delegation board with status and stop.
   • Scheduler, action log, Git, trace capture.
   • Pattern maintainer and proposer, propose-only. Example cases created from your corrections.
   • Console views inside the Obsidian Control Deck, with a minimal approval surface.

   Must demonstrate

   • Zero outbound actions without a matching approval record, checked by provider reconciliation.
   • An injection red-team suite across mail, document, and calendar vectors, with no unapproved actions.
   • Briefing citations resolve to authorized source items.
   • Every scheduled briefing delivered or honestly marked missed.
   • Deletion propagation and source disconnect pass their tests.
   • Agreement between the automated judge and human judgment is measured, not assumed.

3. Stage 2 · Beta · first teams

   A self-hosted node, always on. Product direction

   The same runtime as a container or VM in your own cloud or on your premises, synced through your own Git remote. Unattended cadence, and the first small teams.

   In scope

   • A second ecosystem or a CRM, with read access and gated notes.
   • Communications drafting and delegation follow-up agents. Steer and queue for agents.
   • The full validation gate with gated acceptance switched on. Overnight evolution with a morning report.
   • Rollback and an automatic revert policy. A transfer gate across two model providers.
   • A chief-of-staff role with delegated approvals. Retention tooling.
   • A security questionnaire pack.

   Must demonstrate

   • Gate calibration: where the judge does not agree well enough with human labels, that rubric falls back to human-only.
   • Rollbacks restore the prior version and pass that version's suite.
   • A skill validated on one model is re-gated before use on another. Enforced by the runtime.
   • A node restore from backup and a key rotation drill.
   • The alpha criteria for reconciliation, injection, and deletion still hold.

4. Stage 3 · General availability

   Teams, policy, and independent review. Concept workflow

   Team governance and the controls that today sit under planned on the security page. A managed single-tenant EU option exists only as an undecided possibility, and only if customers ask for it.

   In scope

   • Role-based permissions for teams. Organization-level audit export.
   • Team-curated regression sets.
   • Policy-aware action controls, such as no external sends to new domains without the chief of staff.
   • Retention tooling, a node location you choose, and EU model endpoints where available.
   • Sandboxed execution for delegated tasks. Windows support.

   Must demonstrate

   • A control moves to verified only with a test artifact behind it.
   • An independent penetration test, with critical and high findings closed.

The upgrade path from the local editionProduct direction

A vault that satisfies the local edition’s contracts should migrate unattended. Other vaults get a collision report instead of a guess.

1. The migration is a dry run by default.
2. It runs the health checks first and refuses to proceed on a vault that needs repair.
3. It initializes Git if absent and commits a pre-migration snapshot.
4. It normalizes memory to the extended schema with conservative defaults: internal sensitivity, excluded from learning.
5. It versions each skill and records its purpose.
6. It never touches the wiki, except to validate that harvest links resolve.
7. It requires you to re-approve agent permissions, with the new connector and action-class sections, before anything connects.
8. It writes a migration record, and a corrections entry wherever normalization changed meaning.

What it deliberately will not doDesign principle

A governed operating layer is defined as much by its refusals as its features.

• No autonomous sending, publishing, sharing, purchasing, or accepting invitesStanding permissions exist only for reversible action classes.
• No agent swarms or agent marketplacesIEVA coordinates specialists. It does not release a swarm.
• No fine-tuning on customer dataAnd no cross-customer learning without an explicit, separate consent program.
• No machine writing into the wikiPatterns, traces, and model synthesis never enter it. The harvest rule stays absolute.
• No multi-tenant SaaSNot within this plan's horizon. It contradicts isolation and inspectability.
• No meeting-recording bots in the first two stagesIEVA reads existing transcripts only where you already produce them.
• No HR, employee-evaluation, or hiring use casesThese are excluded from acceptable use.
• No certification or residency claims before verificationThe security page's rule applies here without exception.
• No bespoke chat app replacing Obsidian in the first stageThe console is the Control Deck plus a minimal approval surface.
• No executing agent with access to the full pattern baseExecuting agents get pinned skills and scoped memory only.
• No payments or financial transactions as connector actionsThey are a prohibited action class.

Questions

Is the Advanced Edition available today?

No. This page describes a proposed design and a staged plan. It is not shipped software. The local edition comes first. The Advanced Edition is shaped with a small cohort through the access conversation.

What actually stops an agent from sending an email on its own?

It has nothing to send with. Agents hold read access through scoped proxies and one tool for proposing actions. Write credentials live only in the action gateway, a separate process that accepts only a signed approval matching the exact payload. The gateway never calls a model, so text cannot talk it into anything.

Does Ækora host or see my data?

In the desktop and self-hosted stages the runtime runs on your device or your infrastructure, against your own vault, with connections you authorize. Calls to the model provider you choose, with your own keys, are the exception, and they are disclosed per connector. A managed option is undecided and would change this. We would say so plainly before offering it.

Is IEVA self-improving?

No. Skills improve only through validated, approved changes. One proposal at a time, tested against example cases you approved, shown to you as a diff with results, and live only after you approve it. One action reverts it.

Has the learning loop been proven?

Not yet, and we will not pretend otherwise. The loop adapts the published WikiSkill approach to skill evolution. The community implementation of that approach has not yet demonstrated an accepted live change. So the first stage runs propose-only. Acceptance is switched on only after the gate's judgments have been calibrated against human judgment.

What happens when my laptop is asleep at briefing time?

The briefing runs when the machine wakes and is labeled late, with its original schedule time. A connector error is shown as an error. A quiet morning says no material changes. The always-on node in the next stage removes the laptop constraint.

Which systems will it connect to?

The first cohort uses one ecosystem: Google Workspace or Microsoft 365. Which one is not decided. CRM connectors come in the self-hosted stage and team chat later. Exact permission scopes are verified at implementation time, not promised here.

Can I move from the local edition?

That is the intended path. A migration runs as a dry run by default, takes a Git snapshot first, normalizes memory to the extended schema with conservative defaults, versions your skills, never touches the wiki, and asks you to re-approve agent permissions before anything connects.

What certifications or compliance standards does it meet?

None are claimed. No SOC 2, no ISO 27001, no GDPR certification, no specific encryption or data-residency guarantees. The security and governance page states the rule: a control is called verified only when it exists and has been tested.

What does it cost?

No price is set. Bringing your own model provider keys is the intended default, which keeps provider choice with you. Pricing is discussed in the access conversation and will be published only when it is real.