DEV Community: Norbert Rosenwinkel

I'm Building an AI Assistant in C#. I Don't Want to Rewrite Every Tool.

Norbert Rosenwinkel — Tue, 15 Sep 2026 13:03:17 +0000

I'm building an AI assistant in C#. Some of the code I want it to use already exists in Python or TypeScript.

I could rewrite it. But then every improvement to the original becomes something I have to port, test and maintain. Choosing C# for the application shouldn't mean choosing C# for every capability it will ever have.

Calling a script is easy enough. Deciding what happens when it hangs, which data it can ask the application for, and how to replace it without disturbing the rest of the system takes more thought.

That's why I built WeavePort, an open-source plugin runtime for .NET. I also want to keep other applications small by moving selected functionality and strategies into replaceable plugins. A department that works in Python should be able to contribute useful code without first becoming a C# team.

Start with something worth replacing

Suppose I want the assistant to help compare improvement proposals. One capability could score them using business priorities and risk information. The assistant could explain the results; the application would decide when the calculation is allowed to run and what data it can use. That is an intended use, not a finished assistant integration.

The scoring strategy might use a Python library or rules maintained by another team. Its inputs, outputs and meaning need to stay stable when I change the implementation.

This is the idea behind the repository's Decision Room example. Two participants evaluate three proposals using configurable priorities. Equivalent C# and Python strategies produce the same results. Change the language and the winner stays the same; change the strategy and a different proposal can win.

With the default configuration, “Automate support” wins. Increase the strategy's risk penalty and “Improve documentation” wins instead. The host still runs the same workflow.

Decision Room deliberately leaves out the model. It exercises the capability I would put underneath an assistant: send proposals to a strategy, get evaluations back, and keep control of the workflow in the application. The same capability can serve a backend with no AI at all.

From C# to Python and back

Here is the call in the C# host, after it has bound the selected strategy to a worker:

await using var client = new LocalPluginClient(strategy);
Evaluation evaluation = await client.CallAsync<DecisionRequest, Evaluation>(
    "strategy.evaluate",
    new DecisionRequest(participant.Id, state),
    token);

The request contains the participant and the room state, including the proposals. With Python selected, it reaches this function in the Python plugin:

@app.function("strategy.evaluate")
async def evaluate(request, context):
    weights = context.configuration["priorities"]
    knowledge = await context.call_host("knowledge.read", {})
    scores = {
        p["id"]: p["benefit"] * weights["benefit"] - p["cost"] * weights["cost"]
        - knowledge["risks"][p["id"]] * weights["risk"] * RISK_MULTIPLIER
        for p in request["snapshot"]["definition"]["proposals"]
    }
    return dict(participant=request["participant"], source=knowledge["source"],
                risks=knowledge["risks"], scores=scores, pluginVersion=VERSION)

These are excerpts from the runnable sample. Its setup supplies the binding, domain types, application registration and release constants. The SDK carries the request and result across the process boundary; C# receives an Evaluation. The host then validates that evaluation before committing it to the room's state.

The calculation is intentionally small enough to inspect. Version 1 uses a risk multiplier of one; version 2 uses ten. Selecting an equivalent C# strategy keeps the result. Selecting the stronger risk penalty changes it.

The callback is the more interesting part. Its empty payload is deliberate: the host has already bound the plugin to a tenant and knowledge profile. The application uses that context to select the risk data. The strategy doesn't choose another customer's ID in its request.

WeavePort checks whether knowledge.read is granted. The application decides which records that grant permits. This lets the Python code use application-owned knowledge without carrying its own database integration.

There is still integration work. An existing library needs a wrapper, its dependencies need packaging, and its result needs a meaning the caller can rely on. A typed result won't tell you whether two ranking implementations use the same scale. Those business-contract tests remain the application's responsibility.

Give the process a clear owner

Python plugins run in Python processes. TypeScript plugins run through Node. The .NET host manages those workers; it doesn't execute Python inside a C# worker.

For local stdio execution, requests and responses travel as framed JSON over stdin and stdout. There's no listening port to allocate for each plugin. The host handles startup, deadlines, admission limits and cleanup, and workers can be retained where the configured lifecycle allows it.

Suppose a scoring call stops responding. The application needs a failed call it can handle, and the runtime needs to clean up the worker. It must also avoid silently repeating an operation that may already have changed something. A timeout cannot tell us whether an external side effect happened.

I want to make those lifecycle decisions once and apply them to every strategy I add.

There is a security boundary worth being precise about: these are trusted local plugins, not a sandbox for arbitrary uploaded code. Callback permissions restrict access through the host API. A Python process still runs with its OS user's access to files and the network. Contributions from another department therefore still need review and an approved deployment.

When the capability already speaks MCP

Sometimes the wrapper already exists: a tool comes with an MCP server. In that case, I want to use its existing interface.

WeavePort can launch a trusted local MCP server, discover its tools and invoke them under the same host lifecycle and capacity budgets. One server can expose several functions. No language model has to be involved in calling them.

The separate MCP sample uses text normalization as a minimal API demonstration. After binding its server, the call looks like this:

using System.Text.Json;
using WeavePort.Hosting;

var result = await session.InvokeAsync(
    McpMethods.CallTool,
    JsonSerializer.SerializeToElement(new
    {
        name = "normalize",
        arguments = new { text = " hello   world " }
    }));

The runnable example uses Hosting 0.3.1 and includes binding, discovery with McpMethods.ListTools, and checks for both host failures and tool errors.

I still want the native plugin contract for a strategy like Decision Room, where callbacks into application-owned knowledge are part of the design. MCP is useful for consuming existing tools. It doesn't automatically replace those native callbacks or result streams, and installing a native plugin doesn't automatically expose it to an AI assistant. The application chooses what the assistant may invoke.

The current MCP integration covers local stdio tool discovery and calls. Remote HTTP servers and interactive requests back into the host need a different integration. The MCP guide describes the supported revisions and limits.

Is a plugin worth the cost?

For a small extension written entirely in C#, I would start with an ordinary interface. For functionality that needs independent deployment, several consuming applications or its own scaling policy, I would consider a service.

A managed plugin fits the space I'm interested in: the application owns the workflow and wants to reuse or replace a substantial piece of behavior, possibly written in another language.

Crossing a process boundary still costs something. In a local sequential echo comparison on macOS arm64 with Node 24.21.0 and the released 0.3.0 Hosting assembly, small calls over the native WeavePort protocol averaged about 0.057 ms; MCP calls averaged 0.086–0.101 ms. First calls including startup were about 59 ms and 111 ms respectively. These figures describe that test, not the latency of your tool. The benchmark report includes larger payloads, tail latency and the measurement setup.

I'd pass a useful unit of work across that boundary, such as evaluating a set of proposals. I wouldn't split every arithmetic operation into a separate call.

Try changing the implementation

The easiest way to judge the design is to run Decision Room and swap a participant's language:

git clone --branch v0.3.1 --depth 1 https://github.com/yesbert/WeavePort.git
cd WeavePort
./scripts/decision-room.sh --build --verify

You'll need the .NET SDK selected by global.json and Python 3.11+ with venv and pip. The script builds local packages and prepares a private Python environment. This walkthrough is validated on macOS arm64; the platform notes distinguish that from Windows and Linux source checks.

The walkthrough shows how to change the language, select a different strategy, deny a callback and recover a run. Start by changing only the language, then change the strategy. You can check for yourself which behavior belongs to the application and which belongs to the plugin.

WeavePort is MIT-licensed and still pre-1.0. Its .NET packages are on NuGet; the Python and TypeScript author SDKs are currently built from the repository.

What I want for my assistant is simple to describe: when I find a useful capability, most of the work should be understanding its inputs, outputs and permissions. I want the question to be “Can I use this?” long before it becomes “Do I have to rewrite this?”

Where have you drawn that line in your own backend: a library, a plugin or a separate service?

Disclosure: I maintain WeavePort. AI generated the article text and cover from my design goals, source code and project documentation. I reviewed the draft and directed its revisions.

Intent-driven UIs: an Angular workbench your AI assistant operates

Norbert Rosenwinkel — Tue, 08 Sep 2026 14:14:27 +0000

Over the last months I have heard the same wish from my customers again and again. They want to click less in the UI and have an AI assistant do more of the work. They want to say what they intend, without knowing the UI well. The assistant carries it out, asks when something is missing, and asks for approval when something should not just happen. I have started calling this intent-driven UIs, and I think a good part of business software is heading there.

This tutorial shows one way to build such a thing, as inspiration for your own ideas. We build a small support inbox as a desktop-like workbench in Angular, with a list in the sidebar and a tab per ticket. Then we let an assistant work with it. One rule holds throughout, and it is the reason I am comfortable shipping something like this: the assistant can do nothing the person at the keyboard could not also do by hand.

What we build, and what we count

The inbox has six tickets. The workflow we measure: find the ticket about the blank invoice PDF, assign it to Dana, and reply that the fix ships on Monday.

Path	Clicks	Typed
By hand	5 (ticket, assignee select, the option, reply field, send)	one reply
With the assistant	2, one of them the approval of the reply	one sentence

That is one workflow in one small example, and I am not turning it into a percentage. It shows the shape of the thing. You need Node, the Angular CLI and an API key from OpenRouter. The model is free there; a free key allows about fifty requests a day, and one run costs three to five.

Who provides what

AG-UI is an open protocol between an application and an agent. It describes the tool calling you know from function calling at OpenAI, as a format between frontend and agent. One round, a run in the protocol, goes like this: the application sends the conversation and the list of allowed tools. The agent answers with a stream of events: text for the user, tool calls, their results, and at the end "finished".

Three layers meet in the code, and keeping them apart makes the rest easy:

Layer	Package	What it provides
The protocol	`@ag-ui/core`	vocabulary only: the event types, the shape of a tool and of a tool result
The adapter	`@loomweaver/ag-ui`	the logic on the workbench side: `list()` offers the workbench's commands as tools, `receive(event)` runs a tool call and answers
The agent	your product	talks to the language model and translates in both directions; the generator writes a placeholder

So the platform does not ship a finished assistant. It ships the workbench, the adapter and a generator that writes a starting point into your project. From there on it is your code. If you want the longer version: Whose code is which.

Step 1: scaffold the workbench

ng new assistant-workbench --style=css --ssr=false && cd assistant-workbench

npx @loomweaver/cli init --title "Assistant Workbench" --weaver tickets
npx @loomweaver/cli weaver --id assistant --agent --out src/assistant
npm install

npm start

The shell behind these commands is LoomWeaver, an open-source plugin platform for Angular workbenches, and my own project. I use it because it brings the adapter from the table. Without it, the middle of this tutorial would be a tool registry and a dispatcher.

init installs the platform into the fresh application, replaces the bootstrap wiring with a composition root, and scaffolds a first plugin, tickets. The second command adds the assistant plugin; it records two packages in package.json and says so, which is why npm install runs once more.

After npm start you have a workbench with panes, tabs and a command palette. The tickets plugin has an example command and a view. The assistant plugin has three files under src/assistant/src/lib/agent/: the connection assistant-agent.ts, the panel assistant-agent-panel.ts and the placeholder assistant-agent-source.ts. The placeholder speaks only the events, with no model and no network, so the whole path runs before you have connected anything. Click through it once before you read on.

The panel sits on the right because the plugin registers it that way. docks names the region, padded asks for some air, because the workbench insets nothing on its own:

Generated · src/assistant/src/lib/plugin/assistant.plugin.ts

ctx.registerSurface({
  id: 'assistant.agent',
  title: 'assistant.agent.title',
  icon: 'assistant',
  docks: ['right-panel'],
  padded: true,
  component: AssistantAgentPanel,
});

If you want it on the left, change docks. Which regions exist is declared in src/app/app.config.ts, the file where the whole product is composed; more under Reaching the pane edges.

Step 2: two additions to the app

The Content-Security-Policy in src/index.html allows the app's own origin only. The assistant calls OpenRouter from the browser, so it is added:

Changed · src/index.html

connect-src 'self' https://openrouter.ai;

And the icon bar on the far left, the rail, which so far holds only the tickets icon, gets the workbench's settings gear: an entry in app.config.ts that triggers the built-in command shell.openSettings. Why we want it shows up when we try things out.

Changed · src/app/app.config.ts

...provideRailItems({
  id: 'workbench.settings',
  rail: 'primary',
  icon: 'settings',
  title: 'settings.title',
  anchor: 'bottom',
  order: 20,
  command: 'shell.openSettings',
}),

Step 3: turn an operation into a command

The domain is an object with a signal holding six tickets and the operations list, get, assign, reply and setStatus. It lives in src/tickets/src/lib/tickets/ticket-store.ts, it is in the example, and it is deliberately dull.

The interesting part is how the operations are registered. A command is the thing a button, a shortcut, a palette entry and a menu item all point at together. We replace the generator's example command with five. Here is the one that opens a ticket:

Changed · src/tickets/src/lib/plugin/tickets.plugin.ts

ctx.registerCommand({
  id: 'tickets.open',
  title: 'tickets.open.title',
  description: 'tickets.open.description',
  arguments: [
    { name: 'number', kind: 'text', required: true, description: 'tickets.open.number' },
  ],
  answers: 'tickets.open.answers',
  callable: true,
  run: (_context, args) => {
    const opened = ticketActions.open(String(args?.['number']));
    return { ...opened, replies: opened.replies.map((reply) => reply.text) };
  },
});

Three fields do the work for the assistant, and the adapter turns them into the tool:

arguments becomes the JSON schema. The workbench checks every call against it before run runs.
answers makes the return value the answer. Without it the assistant would be blind to what it just did.
callable: true opens the command to callers other than its own buttons, the assistant included. It is off by default, on purpose.

The description is the text the model reads when it chooses between tools. The one for tickets.list reads:

Lists the support tickets with number, customer, subject, status and assignee. Use it to find a ticket when only its topic is known.

That sentence turns "the ticket about the blank invoice PDF" into T-1041 without a search. Whether you have thought of everything is what npx @loomweaver/cli validate-commands --dir src/tickets tells you. It lists every command and names where an agent would have to guess. More under Callable commands.

Step 4: a list in the sidebar, a tab per ticket

This is what makes it a workbench. Instead of one page we register two surfaces: the list, in the left sidebar, and the ticket, as a tab with its own address tickets/:number.

Changed · src/tickets/src/lib/plugin/tickets.plugin.ts

ctx.registerSurface({ id: 'tickets', title: 'tickets.title', icon: 'tickets',
  component: TicketListView, docks: ['left-panel'] });

ctx.registerSurface({ id: 'tickets.ticket', title: 'tickets.ticket.title', icon: 'tickets',
  component: TicketView, routable: { path: 'tickets/:number' } });

Opening a ticket means opening a tab at that path. The click in the list and the tickets.open command go through the same function, so the two cannot drift apart:

New · src/tickets/src/lib/plugin/tickets-actions.ts

open(number: string, options: { preview?: boolean } = {}): Ticket {
  const ticket = ticketStore.get(number);
  ctx?.openContentTab({
    path: `tickets/${ticket.number}`,
    title: ticket.number,
    titleIsLiteral: true,
    icon: 'tickets',
    preview: options.preview ?? false,
  });
  return ticket;
},

A click opens a preview that the next click reuses, a double click keeps the tab. The ticket view in src/tickets/src/lib/views/ticket-view.ts reads its number from the route; its buttons call the same store functions the commands call. There is no second code path for the assistant. More under Opening tabs from code.

Step 5: human in the loop, which command needs a person

The generated code has a checkpoint that runs before every tool call the assistant makes. This is the human-in-the-loop moment: for certain commands it shows the person at the keyboard a confirmation dialog. If they say no, the command does not run, and the assistant learns that it was declined. We change only one line: which commands need that confirmation.

Changed · src/assistant/src/lib/agent/assistant-agent.ts

const CONSEQUENTIAL = new Set(['tickets.reply']);

A test for what belongs in that set: would you want it to happen while you were looking away? Sending, deleting, publishing, yes. Opening and listing, no, because asking about everything trains people to click the question away.

Step 6: the agent

We replace assistant-agent-source.ts entirely but keep the placeholder's shape: a function that gives off event after event while it works, an async generator in TypeScript. The panel hands it the request:

New · src/assistant/src/lib/agent/assistant-agent-source.ts

export interface AgentRequest {
  readonly runId: string;
  readonly prompt: string;
  readonly tools: readonly Tool[];
  readonly key: string;
  readonly receive: (event: BaseEvent) => Promise<ToolMessage | null>;
}

tools are the tools from list(), asked for again on every round. receive is the door into the workbench: every event goes in there, and for a completed tool call the result comes back. The loop below is the usual tool-calling loop. Ask the model. If it wants to call tools, run them and return the results. Repeat until it answers in words.

async function* ask(history, request, fetchLike): AsyncGenerator<BaseEvent> {
  yield event(EventType.RUN_STARTED, { threadId: 'assistant', runId: request.runId });
  history.push({ role: 'user', content: request.prompt });
  try {
    for (let round = 0; round < MAX_ROUNDS; round++) {
      const message = await complete(fetchLike, request.key, history, request.tools);
      history.push(message);
      if (message.content) {
        yield* say(`${request.runId}.${round}`, message.content);
      }
      const calls = message.tool_calls ?? [];
      if (calls.length === 0) {
        break;
      }
      for (const call of calls) {
        const answer = yield* relay(call, request.receive);
        history.push({ role: 'tool', tool_call_id: call.id, content: answer.error ?? answer.content });
      }
    }
    yield event(EventType.RUN_FINISHED, { threadId: 'assistant', runId: request.runId });
  } catch (failure) {
    yield event(EventType.RUN_ERROR, { message: describe(failure) });
  }
}

complete is one HTTP request to OpenRouter, in the same format as OpenAI's: the conversation plus the tools, translated into its function format. One detail: function names there may not contain dots, so tickets.open travels as tickets__open.

relay translates back. One tool call from the model becomes the protocol's three events, start, arguments, end, and each goes to receive:

const start = event(EventType.TOOL_CALL_START, { toolCallId, toolCallName: commandId(call.function.name) });
yield start; await receive(start);
const args = event(EventType.TOOL_CALL_ARGS, { toolCallId, delta: call.function.arguments || '{}' });
yield args; await receive(args);
const end = event(EventType.TOOL_CALL_END, { toolCallId });
yield end; const answer = await receive(end);

On the end event, the adapter first runs the human-in-the-loop check from step 5, then the command. Back comes the answer for the model: the return value, a refusal or a failure, worded so the model can tell "you may not" from "it broke". Nowhere here is a list of tools or a switch that routes calls; the adapter behind receive does that.

Step 7: the panel

The generator also gave the assistant an example command with a shortcut, a view with a route and a rail item, so that the rail shows something on the first serve. They go now, and the test that pinned the example command goes with them, because the panel is everything this plugin contributes.

The generated panel offered one button per tool. We give it a text field for the sentence and a field for the key, which stays in local storage (openrouter-key.ts) and goes to OpenRouter only. The send method builds the request from step 6:

Changed · src/assistant/src/lib/agent/assistant-agent-panel.ts

const request = {
  runId: `run-${++this.runs}`,
  prompt,
  tools: offered,
  key,
  receive: (event: BaseEvent) => this.receive(tools.receive(event)),
};
for await (const event of this.agent.ask(request)) {
  this.draw(event);
}

The model is one constant, dots-studio/dots-3-note-preview:free. Any free model on OpenRouter with tool calling will do, and you will need another one sooner or later, because the free ones come and go; the list is filtered and the example says so where the constant is.

Try it

Paste the key into the panel and type:

Open the ticket about the blank invoice PDF, assign it to Dana and reply that the fix ships on Monday.

The panel shows what the model does: list the tickets, find T-1041, assign it, and at the reply the workbench asks you. Say yes, and the ticket's tab comes to the front, with Dana and the reply. Say no, and the workbench was never asked. For me the whole thing took under ten seconds. Sometimes the model opens the ticket first, sometimes not; the order belongs to the model, only the boundary is yours.

Then take something away from it. Gear, Permissions, switch off "Run actions other plugins added" under Assistant, close the dialog, click into the input: "0 tools offered".

Ask it something now, and it can do nothing. We did not build that. The adapter asks on every run what the plugin may reach, and the workbench answers with what you left it. More under Permissions.

The boundary, and what changes for production

The checkpoint from step 5 can only say no, never allow more. A yes only means the product has no objection. After that the workbench checks what it always checks: whether the command exists, whether it is callable, whether the signed-in person would be allowed to run it. And every refusal reads the same to the model, so an assistant cannot learn what is installed by asking. Details under What the agent never learns.

For production, nothing in the workbench changes. The key in the browser is fine for a tutorial and not for a product. There the agent runs on your own server, in whatever stack, and the ready-made client @ag-ui/client fetches its events into the same receive() loop. Panel, connection and commands stay as they are. The frontend does not care where the model lives.

The code

The example lives in the LoomWeaver repository, and you can fetch it on its own:

npx degit yesbert/loomweaver/examples/assistant-workbench#tutorial-intent-driven assistant-workbench
cd assistant-workbench && npm install && npm start

The live demo has an assistant panel too, and the guide to AG-UI agents covers what is missing here.

I would be curious what intent-driven UIs look like in your domain, and where the line between "just do it" and "ask me first" falls for you. That line is, I think, the actual design work.

How AI changed the way I build software, and why I ended up building an open source shell for Angular

Norbert Rosenwinkel — Fri, 04 Sep 2026 15:52:38 +0000

Up front: this is my own project, so I'm not exactly neutral here ;-)

Where I'm coming from

I work completely differently than I did two or three years ago. For most of my career I wanted to write pretty much every line myself, and I was a bit proud of that. That has changed a lot. Instead of programming I now mostly write specifications and review what the AI generates. On the one hand that's great, I can turn new ideas into working software much faster than before. On the other hand there's the risk of stepping into the same traps with AI-generated code again and again.

And that's where I noticed something. Every time I started a new project, I found myself explaining the same things to the AI. This goes into a plugin. That stays out of the core. No domain logic in the shell. Please don't invent a third way of doing tabs. The AI would nod, generate something that looked right, and two days later I'd find a slightly different version of the same sidebar with a slightly different bug.

There are things I really don't want to explain over and over. A good, preferably deterministic base is getting more important, not less. I don't want to explain proven architectures from scratch every time. I'd rather build on established solutions where I can, ones the AI understands and can just use.

So for my new projects I built exactly that, and put it on GitHub as open source. Why Angular? Well, simply because I think it's a great framework and I've had a lot of good experiences with it over the last 10 years.

What it is, and what it isn't

LoomWeaver is a workbench shell for Angular. Not a component library. Think of the frame VS Code gives you: a rail on the left, sidebars, a top bar, a status bar, and in the middle tabs and panes you can split and drag around. That frame is what most workbench-style products build themselves, every time, slightly differently. LoomWeaver gives you that frame, and your own domain moves in as plugins.

The core contains zero domain logic. Even my own product UI goes through the same plugin contract a third party would use. That sounds like a purity thing, but it's actually what makes the AI part work, I'll get to that.

Twenty-seven seconds, no cuts. The rail, the panes, the palette and the status bar are the platform's. Everything inside them comes from plugins, the theme at the end included. There's a better quality version on the site.

What's in the box, out of the box:

tab groups with drag-to-split panes, and any tab pops out into its own window
a command palette (⌘K) and quick open (⌘P), with preview tabs and pinning
named workspaces that remember their own arrangement
theming from semantic tokens: bring Tailwind, bring Bootstrap, bring nothing
i18n with namespaced composition, so two plugins can never collide on a key
WCAG 2.1 AA accessibility the host meets and your plugins inherit
an installable PWA with an update flow that actually works
live state sync across windows and tabs
save, discard or cancel when an editor closes with unsaved work
auth-aware chrome: contributions declare the access they need, the shell reacts
a plugin system with three trust levels, from your own in-process code to sandboxed iframes to plugins installed at runtime from a catalog
an AG-UI adapter, so any agent speaking that standard can run your commands

And it ships no server. Settings, session and secrets are ports you implement against your own backend. That's a decision, not a gap. I already have a backend, and so do you.

Five minutes to a running product

This is the whole setup, against a fresh Angular app or the one you already have:

# a fresh Angular app, or the one you already have
ng new my-studio --style=css --ssr=false && cd my-studio

# the platform
npm install @loomweaver/shell @loomweaver/plugin-sdk @angular/cdk @jsverse/transloco \
  @ng-icons/heroicons \
  @angular/service-worker@$(node -p "require('@angular/core/package.json').version")
npm install -D tailwindcss @tailwindcss/postcss @tailwindcss/typography

# your product, and a first plugin already contributing to it
npx @loomweaver/cli distribution --name my-studio --title "My Studio" --out . --force
npx @loomweaver/cli weaver --id notes --command --shortcut 'mod+shift+n' --out src/notes

ng serve

The scaffold writes eleven files and deletes nothing. Your README.md stays yours. And a plugin, which I call a weaver because, well, it weaves on a loom, is a manifest and one activate():

import { Plugin } from '@loomweaver/plugin-sdk';

export const notesWeaver: Plugin = {
  manifest: { id: 'notes', name: 'Notes', capabilities: ['contributions', 'ui', 'host'] },

  activate(ctx) {
    // ctx.registerSurface / registerCommand / registerBarItem / registerRailItem
    // ctx.ui.*  (dialogs, toasts, settings)
    // ctx.host.* (version, update)
  },
};

Capabilities are default-deny. A weaver declares what it needs, the distribution grants it, and everything else is simply not there. What a weaver hands the workbench are ordinary standalone Angular components against the router you already use. Nothing about how you write Angular changes.

The part that's actually about AI

This is the bit I care about most, and it's three things.

The contract is written down, as specs. Everything the platform guarantees lives as one specification per capability in the repo. Not as prose in a wiki, as the thing the tests are derived from. When I change behaviour, the spec changes first. That's what I meant by a deterministic base: my AI assistant doesn't have to guess how tabs work, and neither do I.

Your AI can read it directly. There's an llms.txt and an llms-full.txt on the site, and there's an MCP server. Drop this into your assistant's config and it can scaffold weavers and distributions in your own repository, with the actual contract in front of it:

{
  "mcpServers": {
    "loomweaver": { "command": "npx", "args": ["-y", "@loomweaver/mcp"] }
  }
}

An agent can drive your product, and only as far as the user could. The workbench speaks AG-UI, the open protocol between a user-facing app and an agentic backend. You don't describe your actions a second time. A command you register with callable: true is a tool an agent is offered:

ctx.registerCommand({
  id: 'invoices.export',
  title: 'Export invoices',
  description: 'Export the selected invoices as CSV',
  arguments: [
    { name: 'range', kind: 'choice', choices: ['month', 'quarter', 'year'], required: true },
  ],
  callable: true,
  run: (_context, args) => exportInvoices(String(args?.['range'])),
});

A call from an agent comes back through the same seam a button, a shortcut and the command palette already run through. Permissions and access gating aren't checked again for agents, because they were never bypassed in the first place. If you want a confirmation before the expensive ones, there's a before hook, and it can only narrow, never widen.

No lock-in on CSS

The base layout is built with Tailwind, but you don't need it in your project. The shell ships as a pre-compiled stylesheet, the design tokens are plain CSS variables, so you can put whatever CSS framework you like next to it in its own cascade layer. For Bootstrap there's even a preset that maps the tokens onto Bootstrap's own variables, so both worlds share one palette:

npx @loomweaver/cli theme --preset bootstrap

Plugins don't have to be Angular either. A sandboxed weaver runs in its own iframe with an opaque origin, no reach into your DOM, and you can write its body in React, Vue, Svelte or plain JS. The tour above shows one.

Honest bits

It's young. It targets Angular 22 and Node 24, nothing older. It's for products that are a workbench, several things open at once, a surface other people extend. It is not for a site of plain pages, and it is not a component library, you bring your own buttons. And yes, a lot of the code was AI-assisted. What gets reviewed, tested and released is the contract in the specs, plus a nightly end-to-end suite that actually clicks through the workbench.

I'd be really happy about constructive feedback, the harsher the better. Docs and the live demo are at loomweaver.dev, the code is at github.com/yesbert/loomweaver, Apache 2.0. And if you feel like it, you're very welcome to get involved.

You can't delete an event. GDPR says you must. Crypto-shredding is the truce.

Norbert Rosenwinkel — Wed, 03 Jun 2026 15:24:11 +0000

Two rules that can't both be true

Event sourcing has one rule: you never delete. You append. The log is the source of truth, and rewriting history is the cardinal sin.

GDPR Article 17 has one rule too: when a user asks, you erase their personal data. Not "hide it," not "flag it deleted" — erase it, everywhere, including backups.

Put an event-sourced system in front of a privacy regulator and those two rules collide head-on. The user's name, email, and address are baked into CustomerRegistered, AddressChanged, OrderPlaced — dozens of immutable events, replicated to read models, snapshotted, and sitting in every nightly backup you've ever taken.

"Just delete the events" breaks event sourcing. "Never delete" breaks the law. Most teams discover this tension after they've committed to append-only.

A word on why this isn't academic for me. I build from Germany. Article 17 is EU law — the GDPR, or DSGVO as we call it here — not a German invention, but Germany enforces it about as hard as anywhere in Europe: regional data-protection authorities that issue real fines, and "we were careful" has never been a defense that held up. That pressure is exactly why I wanted erasure to fall out of the architecture instead of being a promise I make to an auditor and then pray I can keep.

Why "delete the row" doesn't actually erase anything

Say you give in and hard-delete the events for one user. You've still got their data in:

every read-model projection rebuilt from those events,
every snapshot that rolled them up,
every backup taken before the deletion,
every replica and every export that already left the building.

Chasing personal data across all of those, provably, on a 30-day regulatory clock, is a nightmare — and a single missed backup tape means you didn't comply. Physical deletion doesn't scale to a system designed to keep everything forever.

Crypto-shredding: delete the key, not the data

The trick is to stop trying to delete the data and instead delete the ability to read it.

Encrypt each subject's personal data under a key that belongs only to that subject. Keep the ciphertext wherever it lands — events, snapshots, backups, replicas. When the erasure request comes in, you don't hunt down the data. You destroy the one key.

The instant that key is gone, every copy of that ciphertext — including the ones on backup tapes you can't even reach — turns into undecryptable noise. The bytes still exist; they're just permanently meaningless. That's crypto-shredding, and it's what makes Article 17 erasure architecturally sound instead of a manual scavenger hunt.

The data model becomes: plaintext is derived, ciphertext is permanent, and recoverability is a property of a key you control.

The tenant-aware twist (so a leak doesn't cascade)

There's a second property worth getting for free here. If you bind the ciphertext to whose data it is, a leaked key from one tenant can't unlock another's.

AES-GCM takes associated data (AAD) — bytes that aren't encrypted but must match at decryption time or the authentication tag fails. Fold the tenant id into the AAD, and a ciphertext encrypted for tenant A simply won't decrypt under tenant B's context — even if the attacker has the right key bytes. The tenant binding is mathematical, not a WHERE tenant_id = ... you hope nobody forgets.

What it looks like in code

This is the model Stratara builds in (a .NET event-sourcing stack), but the technique is framework-agnostic — the pieces are a key store, an AES-GCM encryptor, and a key you can destroy.

Mark the sensitive fields:

public sealed record CustomerRegistered(
    Guid CustomerId,
    [property: EncryptData] string FullName,
    [property: EncryptData] string Email);

Encryption happens at the serialization boundary — when the event is written to the store or the bus, not in memory. Your handler reads customer.Email and gets plaintext; the bytes at rest are sealed.

A key is addressed by a scope — a sensitivity level optionally narrowed to a tenant and/or user:

var scope = new KeyScope(DataSensitivityLevel.TenantScoped, tenantId.ToString());

The store hands out a versioned, KEK-wrapped data-encryption key per scope (never plaintext at rest). Rotation adds a version and keeps old ciphertext readable. And the erasure request — the whole point — is one call:

await keyStore.EraseScopeAsync(scope, cancellationToken);
// every ciphertext under this scope is now permanently undecryptable — backups included

For larger payloads (attachments, exports) the same scope + a purpose label bind a whole stream:

await using var sealedStream = await blobEncryptor.EncryptAsync(
    plainStream, scope, purpose: "attachment", cancellationToken);

What it costs at runtime

The question that always follows "encrypt every sensitive field" is "what does that do to throughput?" Measured: sealing a field with AES-GCM runs around 4 µs per object — a few hundred thousand encrypt operations a second on a single core of a fanless MacBook Air M4, and it parallelizes across them. The number worth knowing is what an object with no [EncryptData] fields costs: about 45 nanoseconds over plain System.Text.Json. Routing everything through the secure serializer is essentially free; you only pay for the fields you actually mark. Encryption stays a per-field decision, not a per-system tax.

The honest limits (because there always are some)

Crypto-shredding is genuinely strong, but it is not magic, and anyone selling it as magic is wrong:

It only shreds what stayed encrypted. Personal data that escaped the encrypted boundary — written to a log line, an analytics event, a search index, a CSV someone emailed — is not under the key and is not shredded. The boundary is only as good as your discipline about what crosses it.
It shreds recoverability, not the bytes. If your threat model requires provable physical destruction, crypto-shredding doesn't give you that — it gives you computational irreversibility, which is what regulators actually accept, but know the difference.
A key extracted before the shred is a key forever. If an attacker copied the DEK while it was live, destroying it later doesn't help for the data they already grabbed. Crypto-shredding protects against future reads of retained ciphertext, not past compromise.
Key custody is now the whole ballgame. You've moved the problem from "delete data everywhere" to "manage and destroy keys reliably." That's a better problem — it's small and centralized — but it's a real one. The data-encryption keys should themselves be wrapped by a master key (KEK) you keep in an HSM / KMS / vault, and your keystore backups need their own erasure story.

Name those, and crypto-shredding goes from a compliance checkbox to an actual control.

Where this earns its keep

Beyond GDPR Article 17, the same per-subject-key model underwrites a lot of the compliance surface teams dread:

SOC 2 / ISO 27001 — demonstrable data-isolation and key-lifecycle controls.
HIPAA — per-patient cryptographic separation.
Multi-tenant SaaS — a leaked row from one tenant is useless against another, by construction.

It turns "we'll be careful" into "the storage layer is careful by default."

The hard part of event sourcing was never the append. It's the two things append-only quietly makes harder — proving nobody rewrote history, and erasing someone who has the right to be forgotten. The first is hash-chaining (I wrote that one up separately). The second is crypto-shredding, above.

The technique drops into any append-only store. If you want it wired — [EncryptData], scoped keys, one-call erasure — it's in Stratara, the .NET stack I maintain; zero-dependency samples in the repo, docs at https://docs.stratara.tech. Source-available under MIT License.

Happy to get torn apart in the comments — especially on the limits. And if the approach earns a place in your toolbox, a star on the repo helps the next person fighting the append-only-vs-Article-17 problem find it.

AI doesn't fail because the model is bad. It fails because there's nothing underneath it

Norbert Rosenwinkel — Sun, 31 May 2026 13:17:48 +0000

There's a question every system runs into the moment it goes to production and starts doing real things: what exactly happened, in what order, against what data — and can you prove it?

AI is just making that question very loud right now. Picture the case that gets more likely with every tool-using agent: a support agent — not a human, an LLM with tool access — cancels a subscription, issues a refund, fires off three follow-up emails. The next day the customer says: I never cancelled. Now answer the question above.

In most codebases the honest answer is: you can see the current state of the database (subscription cancelled), but not the path that got it there. A few log lines the next refactor will overwrite. No reliable record of which actor acted on behalf of which customer. And undoing it means hand-writing a correction and hoping you catch every side effect.

That's not a model problem. GPT wasn't "wrong." The problem sits one layer down.

The AI part is now the easy part

Two years ago the model was the hard part. Today you wire up an agent that calls tools, makes plans, and takes actions in ten minutes. The demo looks fantastic — and that's exactly the trap. A demo doesn't move anything real. The moment something touches real state in production, the problems no better prompt will solve show up:

State: what was the situation when the decision was made? A CRUD table only knows now.
History: which steps led to the outcome? Without a record — gone.
Attribution: who or what acted, and authorized by what?
Reversibility: a wrong action — how do you take it back cleanly?
Trust: can someone quietly rewrite the record afterwards?

This isn't actually an AI problem

And here's the part that matters to me more than all the agent hype: none of this is new, and none of it is AI-specific. A webhook that changes a record at night; a batch job; an admin clicking the wrong button under pressure; a second service writing in over the message queue — they all raise the exact same five questions. State, history, attribution, reversibility, trust are the properties of good software, full stop.

AI did just one thing: it took away your excuse. As long as the only actor was a human managing one click a minute, you could muddle through — grep the logs, guess when in doubt. An autonomous agent firing a hundred actions a second doesn't allow muddling through. It just makes the gap that was always there impossible to miss.

That was the idea behind what I build from the start: not an AI framework, but a foundation for good software. That an agent can run on top is an option — a very current one — but not the point.

What a foundation like that stands on

Nobody needs a particular pattern to ship a feature — I'd never claim that. But the moment a system seriously manages state, no matter who touches it, these three decisions stop being academic:

1. A system of record instead of a snapshot — CQRS + Event Sourcing.
Overwriting fields means throwing the past away. Make each change an immutable event instead, and history is built in, not bolted on. You replay the stream and reconstruct exactly what happened — whether an agent, a job, or a human triggered it. "Undo" becomes a domain-level compensation event instead of a panicked UPDATE.

2. Structure that keeps the volatile at the edge — Clean Architecture + Vertical Slices.
Every integration point is restless — a third-party API, a payment provider, and yes, AI code with its weekly-changing prompts and models. Let that seep into the domain core and it rots it. A clean core in the middle, the volatile as an outer layer — and each capability as a vertical slice (command → handler → events → projection). New things get added without tearing open five layers, and without the new toppling the existing.

3. Trust as a property, not a hope — audit, tamper-evidence, encryption, validation, authorization.
Any actor allowed to change state needs guardrails the system enforces. Every action runs as a command that's validated, authorized, and audited — and the audit records who triggered it separately from whose data it touched, because with an agent acting on a customer's behalf those are two different identities. The record itself is tamper-evident (hash-chained — rewrite a row after the fact and it shows). And personal data stays encrypted per subject and erasable — because neither "the AI did it" nor "that's just the nightly job" is a free pass against GDPR.

Only together do the three give an answer to "what happened — and can you prove it?" that an auditor will believe. That holds for your agent. It holds just as much for everything else.

Where I have to be honest (the limits)

So this doesn't turn into a list of miracle cures: a foundation doesn't make your software correct. It makes what it does provable, replayable, and containable — which is a different thing.

It records what happened, not why a model decided it. An AI black box stays a black box; you log inputs, actions, results — not the causality inside.
It doesn't prevent a dumb action. It makes it visible and handleable via compensation — but the email that already went out, no replay brings back.
It trades "delete data everywhere" for "manage keys and permissions cleanly." Honestly: a better problem — but still a problem.

Build the architecture, not the plumbing

And here's the catch: building this foundation yourself — event store, command pipeline, outbox, projections, audit, encryption, and all the wiring in between — eats months before you've shipped a single feature. So most teams skip it, ship on CRUD, and hit the can-you-prove-it question later at full force — no AI required.

I didn't want to pay those months again for every project. So I built the foundation once, cleanly, and lifted it out of our own products: Stratara, a .NET 10 stack that brings exactly this — CQRS, event sourcing, mediator, outbox, sagas, projections, identity, plus tamper-evident streams and tenant-bound encryption, lockstep-versioned across 22 NuGet packages, à la carte. The idea behind it isn't "AI platform" — it's simply that you build the architecture of your application, not the plumbing under it. That an agent fits safely on top is a nice side effect of the foundation being right.

Fast enough that you actually leave it on

The whole premise was an actor firing a hundred actions a second — so the foundation has to keep up, not buckle under its own audit guarantees. And here's the failure mode nobody admits to: the guarantees are real and slow, so the first time a load test goes red, someone quietly switches them off. Audit sampling drops to one-in-ten. The projection rebuild moves to a nightly cron instead of running live. The thing that was supposed to make the system provable becomes the thing you disable to hit your p99. That's not a foundation — that's a feature flag waiting to be turned off.

So the hot paths don't use reflection. Replaying a stream means calling an Apply method for every event, and the naive way — MethodInfo.Invoke per event — is exactly the cost that pushes people to cut corners. Instead, each apply-method, projection handler, and constructor is compiled once into a strongly-typed delegate (Expression.Lambda(...).Compile()) and cached. After that first compile it's a direct call, not a lookup. A compiled property write clocks about 13× faster than the reflection equivalent on this machine — and because it runs per event, that gap compounds linearly with stream length.

The payoff shows up where it matters, in a full replay:

Events replayed	Time	Allocated
10,000	0.11 ms	64 B
100,000	1.13 ms	64 B
1,000,000	11.6 ms	64 B

A million events in ~12 ms — and, the part I like more, at a constant 64 bytes no matter how long the stream. Replaying a whole history hands the garbage collector essentially nothing to chase. The audit trail you keep for the auditor is the same data structure you replay in single-digit milliseconds for the app. You don't get to pick between provable and fast; you get both or you get neither, and here it's both.

(Measured with BenchmarkDotNet on a fanless MacBook Air M4. Read the numbers as ratios, not server absolutes — a cooled box with real airflow moves the absolutes, not the shape. The benchmark project ships in the repo; dotnet run -c Release reproduces it.)

Scale by adding boxes, not by rewriting code

Speed on one core is table stakes. The harder promise — and the one event sourcing usually breaks — is what happens when the hundred-actions-a-second actually arrive, from many actors, all at once.

The textbook trap is the global lock. To keep one aggregate's events in order, the easy implementation serialises every write, and now your throughput ceiling is one core no matter how many you bought. Stratara takes a different route, and it's worth walking through, because it is the scaling story:

Commands don't block the caller. The default write path is fire-and-forget: a command goes onto a message bus and returns 202 Accepted immediately, while a worker handles it out-of-process. The request thread never waits on business logic, and a traffic spike buffers in the bus instead of pinning your web tier.

Workers compete for the work. The bus — RabbitMQ or Azure Service Bus — hands each message to whichever worker is free. Add replicas (more pods, more nodes) and they share the load automatically. No leader to elect, no partitions to reassign by hand. Scaling out is a number in a deployment manifest.

Ordering survives parallelism — through buckets, not locks. This is the clever part. Every aggregate id is hashed onto one of 4096 buckets, deterministically: the same id always lands in the same bucket. Writes within a bucket serialise through a single-writer lock, so one aggregate's events stay strictly ordered — but different buckets run fully in parallel. Per-aggregate consistency and cross-aggregate concurrency at the same time, with zero global coordination.

4096 is a power of two on purpose (cheap bit-masking instead of a modulo), and every persisted row — events, snapshots, command log, outbox — carries its bucket id and is indexed on it. So the bucket axis isn't only a lock; it's a partition key you can shard the database along too.

Read models keep up by subscribing, not polling. Projections never ask a table "anything new?" on a timer. They subscribe to the bus, and the write path publishes the event bundle the instant it commits. A read model trails its write by a beat, not by a poll interval — and you're not burning idle "is there work yet?" queries when traffic is quiet.

Put together, scaling stops being an architecture project and becomes an operations one. Command, projection, and saga workers all scale as competing consumers; the one deliberate exception is the tamper-evidence hash worker, which stays single-instance by design — it's appending to a single chain, and you don't want two writers fighting over its head.

When the bus drops, nothing waits in line

One more thing the hundred-a-second premise demands: the fast path can't be the only path, or a broker hiccup loses commands.

So the dispatcher tries the bus first — the direct, fast publish. Only if the bus is unreachable does the command land in a durable outbox table, where an OutboxWorker re-publishes it once the bus is back. In the normal case there's no outbox round-trip on the hot path at all; the durable net only engages on failure.

Let me be precise, because this is where marketing usually overclaims: the guarantee is at-least-once, not exactly-once. A command can arrive twice — a retry after a crash mid-publish — so handlers are written to be idempotent, and correlation ids make duplicates detectable. "No message silently lost," yes. "Each message exactly once, by magic," no — and anyone selling you the latter without idempotent handlers is selling you something.

Why this is the floor

None of these techniques is mine to claim — reflection-free dispatch, bucketed single-writer locks, push projections, an outbox fallback all predate me, and you could build any of them into your own append-only store. What eats the months is wiring all of them together cleanly, lockstep-versioned, and keeping them honest under load. That's the part I didn't want to pay for twice. If you're in .NET and you want your next system — with or without an agent on top — standing on something production-grade from day one, this is my floor.

Runnable, dependency-free samples are in the repo, docs at docs.stratara.tech. Source-available under MIT License.

Reading is one thing, building another. Grab the repo, run a sample, put your own first action on top of it — and if it earns a place in your toolbox, a star helps the next person find it. Bring your ideas for where the foundation could get better, here in the comments or as an issue on GitHub. A foundation doesn't get good because one person builds it; it gets good because many people use it and push exactly where it still gives. 😉

Append-only doesn't mean what you'd hope

Norbert Rosenwinkel — Sat, 30 May 2026 15:51:07 +0000

Event sourcing gets sold on immutability. You don't update, you don't delete, you only append, so the history is permanent.

It mostly isn't. The events are immutable because your code agrees not to touch them, not because anything actually stops it. Underneath they're still rows in Postgres, and rows have a DBA with write access. A migration that "cleans up" old data. A 2 a.m. query run against the wrong connection. A backup restored with slightly different bytes in it.

Change one of those rows and a replay won't blink. The aggregate rebuilds, the projections rebuild, everything looks fine. Usually the first person to notice is a customer whose balance is off, and by then the trail is cold.

Chain each event into the next

The trick is small. Give every row two extra columns: a hash of its contents, and the hash of the row before it.

The hash is SHA-256(previousHash || json(payload)). Nothing exotic.

The point is that each hash depends on the one before it. Edit a payload and its hash stops matching. Rewrite that hash to cover for the edit, and now the next row's pointer is wrong. You can't fix one without breaking the next.

About forty lines of it

Appending an event hashes it together with the previous one:

public HashChainedEntry Append(object payload)
{
    var previousHash = _entries.Count == 0 ? GenesisHash : _entries[^1].Hash;
    var hash = ComputeHash(previousHash, payload);
    var entry = new HashChainedEntry(_entries.Count + 1, payload, previousHash, hash);
    _entries.Add(entry);
    return entry;
}

internal static byte[] ComputeHash(byte[] previousHash, object payload)
{
    var payloadJson = JsonSerializer.SerializeToUtf8Bytes(payload, payload.GetType());
    var combined = new byte[previousHash.Length + payloadJson.Length];
    Buffer.BlockCopy(previousHash, 0, combined, 0, previousHash.Length);
    Buffer.BlockCopy(payloadJson, 0, combined, previousHash.Length, payloadJson.Length);
    return SHA256.HashData(combined);
}

Verifying is the same thing backwards. Walk the rows, recompute, and check two things on each one: the pointer and the hash.

byte[] previousHash = new byte[32]; // genesis
foreach (var entry in store.Entries)
{
    if (!ByteArraysEqual(previousHash, entry.PreviousHash))
        throw new EventStreamCorruptedException(entry.Sequence,
            "previous-hash pointer does not match the prior entry's hash");

    var recomputed = ComputeHash(previousHash, entry.Payload);
    if (!ByteArraysEqual(recomputed, entry.Hash))
        throw new EventStreamCorruptedException(entry.Sequence,
            "stored hash does not match a fresh re-hash of the payload (payload was modified after commit)");

    previousHash = entry.Hash;
}

Bump Alice's $50 deposit to $5,000 straight in the table, and the check stops you cold at the exact row:

Event stream tampering detected at sequence #2: stored hash does not
match a fresh re-hash of the payload (payload was modified after commit)

What that gets you

Someone tries to…	…and it shows up because
Edit one event's payload	the re-hash no longer matches the stored hash
Rewrite the stored hash to match	the next row's pointer no longer matches
Delete a row from the middle	the next row's pointer doesn't match its new neighbour
Slip in a forged row	same thing, the pointer chain breaks at the seam

The honest ceiling

Here's the part people gloss over. That table assumes the attacker is lazy: edit a row, move on, leave the stale hash behind. Someone with full write access doesn't have to be lazy. They can edit the row and then recompute every hash after it. Now the chain is consistent again and the verifier has nothing to say.

A hash chain is a checksum, not a signature. If you own both ends of it, so does anyone who owns your database. That's the honest ceiling of doing this inside your own four walls, and it's worth saying out loud before someone says it for you in the comments.

Getting out of your own walls

This is what anchoring is for, and it's the part I find actually interesting.

Next to the per-stream chains, Stratara keeps a second table of anchors. Every so many events it writes down the head of the chain at that point. Each anchor row has a BlockchainTxHash column, and that column is the hook: you take the anchor and commit it somewhere you don't control. A public blockchain. An RFC 3161 timestamp authority. An OpenTimestamps calendar. A notary. Anything you trust that isn't you.

Once an anchor lives somewhere out of your reach, the recompute attack falls apart. Your insider can rewrite every hash in the database and still can't touch the value you already pinned elsewhere. The question stops being "is this chain internally consistent" and becomes "does it still match what we committed outside." That second one is much harder to fake.

Let me be straight about what ships versus what you wire yourself. The anchor table, the worker that writes anchors, and the BlockchainTxHash column are in the box. Actually pushing an anchor to your source of truth, and checking against it later, is the part you wire up. Stratara doesn't pick the chain for you, the same way it doesn't pick your message broker. The sample at the end runs the whole thing in memory so you can see the shape of it.

One caveat, said plainly: if someone owns your database and your anchoring pipeline, they can re-chain and re-anchor and it'll all look fine. The defense only holds if the thing you anchor to is genuinely out of their hands. That's the entire reason to put it outside.

Where the hashing happens, and where verifying does

The hashing runs on a background worker, not inline on every append, so writes stay cheap. And cheap is measured, not hoped: hashing a typical event takes well under a microsecond — around 700 ns on a fanless MacBook Air M4, riding the chip's hardware-accelerated SHA-256 — so the chain worker stays comfortably ahead of a brisk write rate. The chain gets filled in a beat behind the commit. Verifying is a separate thing you do on purpose: a scheduled job, or checking the external anchor. You don't want it on the read path, because that's a SELECT … ORDER BY Sequence on every query and it ties each read to the integrity check.

Worth being straight about: nothing in the framework wakes up and hunts for tampering on its own today. The hashes and the anchors are there so that when you verify — on a schedule, during an audit, after an incident — the evidence is intact and a break lands on the exact row. For a SOC 2 or ISO 27001 audit, the worker's structured logs are the running record that the hashing happened across the period; the verification job is what proves the chain held.

Where this lives

I build Stratara, a CQRS and event-sourcing stack for .NET 10. The chaining is the EventStreamHashing worker, running against Postgres. None of the idea is Stratara-specific though. If you've got an append-only table, you can bolt this on yourself.

The TamperProof sample is the whole story in zero-dependency, in-memory code, in three acts: a clean chain that verifies, a sloppy tamper caught at the exact row, and a full re-chain that sails past the local check but gets caught by an external anchor.

Wiring it into a real app is more than one dotnet add — you need the event store, the hashing worker, and a little DI — so the getting-started guide walks the minimal setup. Full docs are at https://docs.stratara.tech, and it's source-available MIT License.

This is just one slice of Stratara, and honestly the easiest to show off. There's plenty more I want to write up — the tenant-aware encryption side especially, where a tenant's data is cryptographically bound to their own key — without cramming it all into one wall of text. So if this was your kind of thing, stick around: more coming.

If you're already event sourcing: how would you actually prove to an auditor that nobody's touched the log? Genuinely curious what people are doing here.