DEV Community: Mohsen Seyedkazemi Ardebili

Find where two AI agent runs diverged

Mohsen Seyedkazemi Ardebili — Sat, 10 Oct 2026 09:41:50 +0000

Your agent gave one answer yesterday and a different one today. Same code, same input file, a different decision. Before you can fix anything you need to know where the two runs parted ways. Did the prompt change, did the model reply change, or did something after the model call change?

This tutorial is for engineers who run agents in Python and want to answer that from two recorded runs instead of from memory. You will capture two runs as Run Capsules, compare them with nova diff, read which model call changed, and turn the same comparison into a CI gate. Every command and output below was captured from the released novafabric 0.104.0. Long paths and skipped lines are marked with ….

What you need

Python 3.12 or newer (the package declares Requires-Python: >=3.12)
pip install novafabric openai
The examples/blackbox_demo/ directory from the public MSKazemi/novafabric repository, copied into an empty working directory. Run every command from that working directory.

No API key and no hosted model are involved. The example ships a small OpenAI-compatible mock server on 127.0.0.1:9099.

The scenario

agent.py reads a payment-service config, asks a model for one recommended change, and writes the answer to outputs/decision.json. The mock server answers in one of two ways, chosen by a request header the agent sends: a risky answer (disable rate limiting) or a safe one (reduce max_connections). That gives you two runs whose behaviour differs for a known reason, so you can check that the diff points at the right place.

Step 1: start the mock model

python blackbox_demo/mock_llm_server.py &
export OPENAI_API_KEY=sk-demo-no-key-needed
export OPENAI_BASE_URL=http://127.0.0.1:9099
export NOVAFABRIC_SUGGEST=0

Step 2: capture the first run

nova capture wraps the command with no code changes. Model calls from Python workloads are recorded automatically.

$ nova capture -- python blackbox_demo/agent.py --mode bad
✓ Capsule written: …/.novafabric/capsules/01M4FBTQ7FVQEZBWQGFD2RVTW2

Keep the capsule path in a variable (your run IDs will differ):

BAD=$HOME/.novafabric/capsules/01M4FBTQ7FVQEZBWQGFD2RVTW2

Step 3: capture the second run

$ nova capture -- python blackbox_demo/agent.py --mode fixed
✓ Capsule written: …/.novafabric/capsules/01M4FBVEZDG7XVBYJBB9WD6Q8D

Step 4: diff the two runs

$ nova diff "$BAD" "$FIXED"
  changed=3  added=0  removed=0

Model calls:
  ~ call at span 5fef2505ba0bd78e
Outputs:
  ~ outputs/decision.json
  ~ outputs/stdout.txt

Three items changed (~): one model call and two output files. Nothing was added or removed. For the machine-readable record, add --output-format json; the model-call pair reports request_changed: false and response_changed: true.

How to read it

aligned: 1: the diff paired the one model call in each run.
request_changed: false, response_changed: true: the agent sent the same request both times and got a different reply. The runs diverged at the model's answer, not in your prompt-building code.
environment.changes: []: no recorded environment difference to chase.
outputs: both files changed downstream of that reply.

Step 5: use it as a CI gate

--assert-no-regressions makes nova diff exit 1 when it finds any structural change between the two runs, including added or removed calls. Comparing a run with itself exits 0. On GitHub Actions, --output-format github-annotation prints one annotation per change.

Read the gate for what it is: it answers "did anything change?", not "did it get worse?". A safer answer fails it just as a riskier one does, as it did here.

What this does not do

It does not judge the change. The diff is structural: it tells you which call and which files differ, not whether the new behaviour is better.
Any difference counts. Against a live model, two runs of the same prompt can return different text, and the gate fails on that too.
Automatic model-call capture is for Python workloads. Other clients go through nova api-proxy.
Sealing is opt-in and was not used here. The capsule format is pre-1.0.

The full version, with every command output, the replay section and the CI examples, is on the original page: https://novafabric.ai/blog/find-where-two-agent-runs-diverged/

Originally published at novafabric.ai. NovaFabric is open source (Apache-2.0) and pre-1.0: github.com/MSKazemi/novafabric.

I got tired of typing, so I built a free, offline voice-typing tool (open source, contributors wanted)

Mohsen Seyedkazemi Ardebili — Thu, 08 Oct 2026 15:04:54 +0000

I built YazSes: hold a key, speak, release, and your words are typed into whatever app has focus. It runs speech-to-text locally (faster-whisper on CPU), so nothing leaves your machine: no cloud, no account, no API key.

Install

Linux

curl -fsSL https://raw.githubusercontent.com/MSKazemi/yazses/main/install.sh | bash

Snap

sudo snap install yazses
sudo snap connect yazses:audio-record   # microphone
sudo snap connect yazses:raw-input      # hold-to-talk key

macOS (Apple Silicon)

brew tap MSKazemi/yazses && brew trust MSKazemi/yazses && brew install --cask yazses

Windows

winget install MSKazemi.YazSes

Any OS with Python 3.11+

pipx install yazses

Then:

yazses quickstart   # 3 steps tailored to your machine, read-only
yazses doctor       # verify microphone, hotkey and text injection

Why offline?

Your voice never leaves the machine.
No subscription, no API key, works without internet.
It also transcribes recordings and captures meetings with speaker labels, locally.

Want to contribute? Here is where you can help in 15 minutes

You do not need to be a speech-recognition expert. Real, open tasks right now:

🌍 Native speaker of Persian, Urdu, Thai, Vietnamese, Telugu, Ukrainian, Traditional Chinese...? Several translations of the docs have never been read by a native speaker. Fixing a sentence is a valid first PR.
🧪 Pick a good first issue: https://github.com/MSKazemi/yazses/labels/good%20first%20issue
🐧 Test it on your distro / desktop (Wayland, X11, Windows, macOS) and open an issue with the output of yazses doctor. Bug reports from real machines are gold.
📖 Read the guide: https://github.com/MSKazemi/yazses/blob/main/.github/CONTRIBUTING.md

The test suite runs offline (no microphone, no model download), so you can run it in a minute:

uv sync
uv run python -m pytest tests/ -v

Try it, then tell me

⭐ Star the repo so others can find it: https://github.com/MSKazemi/yazses
⬇️ Install it with the one-liner above and run yazses doctor.
💬 Comment below with your OS and what happened. I reply to every comment.

AI Agents Need More Than Logs: Why I Built NovaFabric

Mohsen Seyedkazemi Ardebili — Wed, 07 Oct 2026 10:10:58 +0000

AI agents are becoming more powerful.

They can:

modify code
call APIs
execute shell commands
change cloud infrastructure
read and write files
interact with other agents
make decisions

But there is a simple question that is still surprisingly hard to answer:

After an AI agent finishes its work, can we prove what it actually did?

Usually, the answer is: not completely.

That is the problem behind NovaFabric.

Logs are useful, but logs are not evidence

Today we have many good observability tools. They can show things like:

Agent started
↓
LLM called
↓
Tool called
↓
API called
↓
File modified
↓
Agent finished

This is useful for debugging. But imagine that six months later something goes wrong. An auditor, security engineer, researcher, or developer may ask:

Which model was used?
What prompt did it receive?
What did the model return?
Which tools did the agent call, and with what arguments?
Which files changed?
Which network services were contacted?
What software versions were installed?
Were secrets captured?
Was the record changed after the run?
Can we reproduce or inspect the execution again?

A traditional trace does not necessarily answer all of these questions. And more importantly, a normal database record can potentially be changed later.

That is where the idea of execution evidence becomes useful.

Think of an AI run as an artifact

NovaFabric takes a different approach. Instead of thinking:

AI Agent → Logs

it thinks:

AI Agent
   ↓
Execution
   ↓
Portable Evidence

NovaFabric captures a run into something called a Run Capsule: a structured folder describing one execution.

capsule/
├── capsule.yaml
├── trace.jsonl
├── model-calls.jsonl
├── tool-calls.jsonl
├── env.lock
├── redaction-proof.json
├── replay.yaml
└── ...

The idea is simple:

The execution should leave behind something you can keep, inspect, compare, replay, sign, and share.

The research paper models the capsule using 15 entity types, including model calls, tool calls, file events, network calls, human approvals, environment information, lineage, redaction records, replay information, and tamper-evidence.

Five verbs explain most of NovaFabric

Capture → Seal → Replay → Diff → Audit

1. Capture

First, capture what happened during the execution:

nova capture python my_agent.py

NovaFabric can wrap a command without requiring the application itself to be rewritten. It aims to capture model calls, tool calls, files, network activity, environment, inputs and outputs. The result is a portable Run Capsule.

2. Seal

Capturing information is not enough. If somebody modifies the record afterward, we want that modification to be detectable.

NovaFabric combines established technologies:

DSSE for signing
RFC 3161 trusted timestamps
Merkle logs for append-only history
cryptographic redaction records

The important point: NovaFabric is not inventing new cryptography. It combines existing standards into one evidence system for AI-agent executions. That integration, rather than a new signing algorithm, is the paper's main contribution.

Before sealing:  "This file says the agent did X."

After sealing:   "This file says the agent did X,
                  and we can detect if somebody changes it later."

There is an important limitation here. Tamper-evident does not mean tamper-proof. NovaFabric can detect later modification of properly sealed evidence. It cannot prove that a trusted signing party told the truth when the evidence was originally created. The paper explicitly defines this trust boundary.

3. Replay

AI systems have another problem: reproducibility. Run the same prompt tomorrow and you may not get the same answer. So NovaFabric does not pretend every AI execution can be reproduced bit-for-bit. Instead, it defines four replay modes:

Forensic replay - execute nothing; reconstruct and inspect what happened (incident investigation, security review, audit, debugging).
Mocked replay - use previously recorded model responses instead of calling the model again, to test the surrounding application logic.
Exact replay - try to recreate the same environment, model, data, and execution, when deterministic conditions exist.
Semantic replay - run against another model and compare the meaning of the new output with the original, e.g. when upgrading from Model v1 to v2.

The paper is deliberately careful here: only the mocked mode is deterministic by construction with respect to model inputs, while forensic mode executes nothing.

4. Diff

Run B produces a bad result. What changed? Maybe the model, the prompt, a dependency, a tool response, the environment, or the output. NovaFabric provides a structural diff between capsules, comparing the structure of runs instead of giant text logs.

In the paper's controlled experiment, structural diff correctly localized all 140 injected mutations across seven tested mutation classes. That could make questions like this easier to investigate:

"It worked yesterday. Why did the agent fail today?"

5. Audit

Finally, the evidence can be packaged into an Evidence Bundle. Another person should not have to trust your database; you can hand them a portable artifact containing the evidence and the cryptographic information needed to verify it.

Agent execution → Run Capsule → Cryptographic seal → Evidence Bundle → Auditor / Researcher / Security Team

The paper specifies an offline verification path using standard technologies rather than requiring the verifier to trust a NovaFabric server. However, it also states that this independent-verifier interoperability path had not yet been exercised by an independently implemented verifier at publication time. That distinction matters.

Why not just use OpenTelemetry?

I like OpenTelemetry, and NovaFabric uses OpenTelemetry concepts. But the problems are different:

Observability	Execution evidence
What is happening?	What happened?
Find errors	Reconstruct the execution
Metrics and traces	Portable run artifact
Operational debugging	Audit and forensics
Usually mutable storage	Tamper-evident evidence
Live system	Historical execution

NovaFabric is not intended to replace Prometheus, OpenTelemetry, Langfuse, LangSmith, or similar systems. It focuses on another question:

Can a past execution be replayed, compared, and proven?

What about secrets?

Capturing everything creates another problem: an agent may see API keys, tokens, passwords, or credentials, and you do not want them inside a bundle sent to another company or auditor. NovaFabric includes secret redaction and a redaction attestation.

But a redaction attestation means "the scanner says it detected and removed this secret." It does not prove that an unknown secret does not exist somewhere else in the capsule. The paper makes this explicit: completeness depends on the scanner, its rules, and the locations it checks. Being clear about these boundaries is especially important for security tools.

What did the research evaluation find?

Model calls captured:                 100% in tested scenarios
MCP tool calls captured:              100% in tested scenarios
Tested tampering classes detected:    3 / 3
Structural mutations localized:       140 / 140
Redaction (14 credential types):      14 / 14 removed
Provenance graph, 10M-edge blast-radius p99:   45.5 ms
Provenance graph, 100M-edge single-client p99: 167.9 ms

But some results exposed weaknesses too. Mocked replay avoided live model calls in 10/10 tested scenarios, but only 2/10 tool-using workloads completed, because tool responses were not yet being substituted in the evaluated version. That was one of the most useful outcomes of the research: the evaluation did not only produce good benchmark numbers, it found real defects.

An unexpected lesson

"The pipeline ran successfully" is not the same as "the evidence is correct."

Several problems were discovered because the tests checked what should have been recorded, rather than simply checking whether the program exited successfully. At one point some evidence streams were missing even though capture appeared to work. In another experiment, an ingest service returned successful HTTP responses even though its configured metadata database had no tables.

"Did it run?" is a weak test.
"Can we prove the expected things actually happened?" is a much stronger one.

NovaFabric today

NovaFabric is open source and self-hosted. The project has moved beyond the exact version evaluated in the paper, so the paper should be read as a research snapshot, not a complete description of today's repository.

pip install novafabric

nova capture python my_agent.py
nova validate <capsule>
nova replay <capsule> --mode forensic
nova diff <capsule-a> <capsule-b>

The project is still beta. Some local functionality is more mature, while server, cluster-scale, and some at-scale components remain experimental. I do not want to describe experimental infrastructure as production-proven.

The bigger idea

As AI agents move from chat interfaces into systems that actually do things - changing production infrastructure, approving financial operations, modifying software, moving important data, operating HPC systems, coordinating other agents - observability alone will not be enough. Eventually someone will ask: What exactly happened? Can you prove it? Can you reproduce it?

That is the space NovaFabric is exploring. Not another agent framework, not another tracing dashboard, but infrastructure for turning an execution into something we can capture → seal → replay → compare → audit.

Try it

NovaFabric is Apache-2.0 and open source:

GitHub: https://github.com/MSKazemi/novafabric
Website: https://novafabric.ai
Research paper: https://arxiv.org/abs/2609.12582

If you work on AI agents, MLOps, HPC, security, observability, provenance, or reproducibility, I would love your feedback. Especially this question:

When your AI agent makes an important decision today, what evidence will you still have six months from now?

YazSes

Mohsen Seyedkazemi Ardebili — Wed, 23 Sep 2026 11:32:26 +0000

Help Us Build an Open, Offline Hands-Free Desktop

Mohsen Seyedkazemi Ardebili — Wed, 23 Sep 2026 11:31:04 +0000

YazSes started with a simple idea:

Hold a key, speak, and have your words typed into almost any desktop application — locally, without sending your audio to a cloud service by default.

GitHub:

👉 https://github.com/MSKazemi/yazses

But voice is only one part of hands-free computer interaction.

What if the same open-source project could eventually let you:

look toward a window and dictate into it,
look roughly at something and say “close this”,
move a pointer using your head,
use an intentional facial gesture as a switch,
use dwell when another physical switch is unavailable,
combine gaze + speech + head movement + switch input,
and safely fall back when the camera is uncertain?

That is the direction of the YazSes eye / camera control programme.

And this is an invitation to help us build it.

First: this is not “perfect eye tracking with a laptop webcam”

This distinction is important.

A normal laptop webcam is not the same thing as a dedicated infrared eye tracker.

We do not want to pretend otherwise.

Commodity-camera gaze may be useful for answering a coarse question such as:

Which window or region is the user looking toward?

It should not automatically be treated as a precision mouse pointer capable of selecting a tiny icon or placing a text caret.

Our current design gives different modalities different jobs.

Task	Input that may fit it best
Generate text	Speech
Choose a pane/window	Coarse gaze
Resolve “this” or “that window”	Gaze + speech
Move a pointer continuously	Head pose
Commit an action	Face switch, voice, dwell, keyboard, EMG, etc.
Precision gaze pointing	Future dedicated eye-tracker backend
Recover from uncertainty	Current focus, voice controls, keyboard/switch, or explicit abstention

One principle from the design summarizes this:

Perception proposes; an intent-bearing action commits.

Your eyes can help say where.

Your voice or another deliberate action can say what to do.

That matters because our eyes are always looking at something.

Looking at a button should not automatically mean clicking it.

Some gaze functionality already exists

This is not just a concept document.

YazSes already contains working gaze-related code.

Glance-Type gaze routing

The implemented gaze path can sample webcam gaze, use a calibration map, resolve a target window, and route the next dictation toward it.

When confidence is insufficient, it falls back rather than blindly choosing another window.

The relevant runtime code already exists in the repository:

src/yazses/gaze/mediapipe_backend.py
src/yazses/gaze/calibrate.py
src/yazses/gaze/targeter.py
src/yazses/gaze/route.py

Look-to-window routing is currently associated particularly with the X11 desktop path, and cross-platform semantics are one of the things we still need to improve.

Gaze + speech deixis

YazSes also has a particularly interesting interaction:

look + speak

For example:

“focus that window”

or:

“close this”

The speech provides the operation while the gaze snapshot provides context for what this or that refers to.

Destructive gaze-routed actions can go through confirmation instead of being executed blindly.

The important part is that gaze provides context rather than becoming an automatic click mechanism.

Other pieces already exist — but are not complete runtime features

This is where the project becomes interesting for contributors.

Several useful cores already exist.

Implicit gaze calibration

There is already a pure implicit-calibration implementation:

src/yazses/gaze/implicit.py

It can update a calibration model from (gaze, click) observations using recursive least squares.

It also contains important safeguards:

reject low-confidence samples,
reject extreme residuals,
use a forgetting factor,
compare a candidate calibration against a baseline,
keep the original calibration unless the candidate performs better on held-out samples.

But the pure estimator is not the same as a complete feature.

The runtime still needs proper opt-in click observation, sample association, persistence and rollback work.

Head-Pointer is another example

YazSes already contains the pure head-pose-to-pointer core:

src/yazses/headpointer/pointer.py

Including:

yaw/pitch → cursor delta mapping,
a configurable dead zone,
and a dwell-click state machine.

Conceptually:

head movement
      ↓
  yaw / pitch
      ↓
dead zone + mapping
      ↓
pointer movement
      ↓
optional dwell

But this is not currently a complete Head-Pointer desktop feature.

The missing engineering includes:

shared camera/head-pose input,
a platform-neutral pointer interface,
X11 output,
Wayland output,
macOS output,
Windows output,
pause/resume,
recentering,
signal-loss handling,
dwell feedback,
and reliable emergency stopping.

A continuous accessibility control without a dependable stop path is not something we want to ship.

Face gestures should become switches — not direct actions

Another planned capability is deliberate facial input.

Imagine intentionally:

opening your mouth,
raising your eyebrows,
making another calibrated expression,

and having that produce an abstract switch event.

Not:

eyebrow movement → directly click something

but:

camera
   ↓
face/blendshape signal
   ↓
gesture detector
   ↓
abstract switch event
   ↓
user-configured action

That difference matters.

The camera detector should recognize intent.

It should not contain desktop-action policy.

The eventual switch could be mapped to things such as:

start/stop dictation,
click,
confirm,
cancel,
pause the pointer,
participate in a gesture chord.

YazSes already has an input-agnostic Gesture Chord core:

src/yazses/gesture/chords.py

But the Face-Gesture Switch itself does not currently have a runtime detector/adapter implementation.

That distinction was important enough that we are currently correcting stale documentation which previously implied otherwise:

👉 https://github.com/MSKazemi/yazses/pull/541

One camera, not three competing camera loops

If gaze, head pose and facial switches all use the same webcam, each feature should not independently open the camera and run its own face model.

The architecture under review proposes a shared perception source:

                         camera
                            |
                            v
                  +-------------------+
                  | Shared Perception |
                  | one camera owner  |
                  | one face model    |
                  +---------+---------+
                            |
          +-----------------+-----------------+
          |                 |                 |
          v                 v                 v
      GazeSignal       HeadPoseSignal      FaceSignal
          |                 |                 |
          v                 v                 v
      calibration       Head-Pointer      Face Switch
          |                 |                 |
          +-----------------+-----------------+
                            |
                     safety / feedback
                            |
                         YazSes

Raw frames stay inside the perception layer.

Consumers should receive small derived signals.

That has several advantages:

one webcam owner,
less duplicated computation,
fewer camera-contention bugs,
easier testing,
clearer privacy boundaries,
easier failure handling.

It also means most of the system can be tested with deterministic numeric inputs rather than requiring a physical webcam in CI.

Privacy needs to be part of the architecture

Camera-based accessibility software deserves careful handling of data.

For this programme, the intended boundary is straightforward:

Camera processing stays local.

Raw webcam frames should not become part of normal logs, evaluation exports, issue reports or network requests.

For engineering evaluation, we care about derived measurements such as:

target successes,
wrong-target events,
fallback events,
calibration error,
confidence,
false activations,
accidental clicks,
pointer acquisition time,
recovery after signal loss,
display resolution and scaling,
OS/session,
broad camera category.

We do not need public contributors to upload:

face photos,
face videos,
raw webcam frames,
private screen contents,
private dictated text,
medical information,
passwords or tokens,
device serial numbers.

There is another important boundary.

Public GitHub QA is not automatically research participation

We eventually want good evidence about whether these interfaces actually work.

But a person who posts an engineering result on GitHub should not silently become a participant in a research paper.

The programme therefore separates:

CI / synthetic evidence
        ↓
community engineering QA
        ↓
separately consented research

A future human-participant study should have its own protocol and consent process.

That separation is already part of the planning work.

“It worked on my laptop” is not enough

Camera interaction can vary dramatically between environments.

We eventually need evidence across:

Windows,
macOS,
Linux X11,
GNOME Wayland,
KDE Wayland,
different webcams,
different laptops,
different screen resolutions,
display scaling,
multi-monitor configurations,
different people,
repeated sessions.

The programme therefore proposes an evidence ladder ranging from pure deterministic tests to real hardware and, separately, controlled human studies.

The basic idea is:

pure unit/state tests
        ↓
cross-platform contract tests
        ↓
synthetic trace replay
        ↓
one real computer
        ↓
another physical computer
        ↓
different people
        ↓
repeated sessions
        ↓
controlled research study

A green unit test does not prove webcam usability.

One working laptop does not prove Windows, macOS or Linux support.

And 1,000 trials from one person are still not 1,000 participants.

We also want to explore semantic grounding

One research/development direction is especially interesting.

Instead of asking the webcam to become dramatically more precise, perhaps precision can come from combining coarse spatial information with UI semantics.

Imagine looking approximately toward a group of controls and saying:

“click Save”

The gaze or head pointer gives an approximate region.

The operating system accessibility tree can provide structured nearby candidates.

Speech provides the requested operation.

Then the resolver can produce:

grounded target

or:

ambiguous — don't guess

or:

unresolved — don't act

Conceptually:

coarse gaze / pointer location
              +
structured UI candidates
              +
spoken intent
              ↓
       target resolver
              ↓
 grounded / ambiguous / unresolved
              ↓
         safety policy
              ↓
            action

The current proposal deliberately starts with structured accessibility information rather than making screenshots, OCR or vision-language models the default.

If structured UI data is insufficient, we should measure that gap first.

Where are we today?

This is important:

The complete hands-free system described in this post is not released.

As of September 23, 2026, the architecture, implementation sequence, evaluation model and contributor workflow are being reviewed in:

👉 https://github.com/MSKazemi/yazses/pull/413

The umbrella hands-free epic is:

👉 https://github.com/MSKazemi/yazses/issues/102

PR #413 is a planning / architecture / evaluation PR.

It does not itself ship:

Head-Pointer runtime,
Face-Gesture Switch runtime,
dedicated eye-tracker support,
a completed hands-free preset,
research results,
or new webcam data collection.

This separation is deliberate.

We want the architecture, privacy rules, safety boundaries, testing approach and dependencies to be understandable before dozens of implementation PRs start landing.

There is also active repository coordination work around the design records, including an ADR-numbering collision tracked in:

👉 https://github.com/MSKazemi/yazses/issues/524

So please treat the live issue status as authoritative rather than assuming every visible eye-control issue is ready for implementation.

We are looking for contributors

This is the main reason for this post.

If you have experience with any of these areas, we would really value your help:

Python
MediaPipe
computer vision
assistive technology
accessibility engineering
HCI
gaze interaction
head tracking
switch access
AAC
Windows UI Automation
macOS Accessibility APIs
Linux AT-SPI
X11
Wayland
XDG Desktop Portal / RemoteDesktop
pointer/input architecture
testing
privacy engineering
human-subject evaluation
technical documentation

You do not need expertise in everything above.

The roadmap is intentionally decomposed so contributors can work on small pieces.

Expected early implementation areas after the planning gate include things such as:

shared perception signal contracts,
a platform-neutral PointerSink,
deterministic evaluation schemas,
safe gaze-calibration plumbing,
accessibility-tree target contracts,
privacy-safe evaluation tooling.

But please check the issue before starting.

The rule is simple

For eye-control work:

Start an implementation issue only when its live issue says READY and has the help wanted label.

For coding-agent work, the repository uses an additional agent-ready gate.

A visible PLANNED issue exists so people can understand the roadmap. It does not mean the dependencies are ready.

You will also be able to help without writing code

Real hardware testing will eventually be extremely important.

The project has planned small validation slots for:

Windows,
macOS,
GNOME Wayland,
KDE Wayland,
X11,
HiDPI,
multi-monitor setups,
repeated-session testing.

Those tasks are intentionally being kept small.

The goal is eventually to let somebody run one defined test pack on one computer and report:

PASS / PARTIAL / FAIL / BLOCKED

A failure is useful evidence.

But those hardware slots are not ready yet.

They depend on the local evaluator and relevant runtime/safety features being completed first.

Please don't invent your own data-collection process for them.

Accessibility experience is as valuable as code

There is another kind of contribution that matters even more.

If you use or support someone who uses:

eye tracking,
switch access,
AAC,
head tracking,
dwell interaction,
alternative pointing devices,
hands-free computing,

we would like to hear from you.

Developers should not decide accessibility defaults simply by asking:

“What feels comfortable to me?”

Questions such as these need experience and evidence:

How long should dwell be?
Which facial gestures are practical?
Which gestures cause fatigue?
What should happen when tracking disappears?
How should pause/recovery work?
What causes accidental activation?
What feedback is necessary?
Which controls must always remain independently disableable?

If our assumptions are wrong, finding that out before implementation is much cheaper than finding it out after release.

How to get involved right now

Start here:

👉 YazSes repository
https://github.com/MSKazemi/yazses

Then look at:

👉 Hands-free / accessibility epic #102
https://github.com/MSKazemi/yazses/issues/102

👉 Eye/camera architecture and evaluation PR #413
https://github.com/MSKazemi/yazses/pull/413

👉 General contributor guide
https://mskazemi.com/yazses/contribute/start.html

Right now, reviewing PR #413 and challenging the design is genuinely useful.

Tell us:

what assumption is wrong,
which failure mode we missed,
which platform API we should use,
whether the proposed abstraction is unnecessarily complicated,
whether an accessibility interaction would be uncomfortable,
whether the test plan measures the wrong thing.

A thoughtful:

“This architecture will fail because…”

can be more valuable than a large pull request.

What I hope we can build

The goal is not an impressive webcam demo.

The goal is a practical, open-source multimodal hands-free desktop control layer.

Something where a person can:

Speak to create text.

Glance to provide context.

Move using head pose.

Commit using a deliberate switch, dwell, voice or another input.

Combine modalities instead of depending on one perfect sensor.

Stop the system immediately when needed.

Fall back safely when confidence disappears.

And do the processing locally on their own computer.

There is a lot left to build.

That's exactly why we are inviting people in now, while the architecture and implementation boundaries are still open to improvement.

If this is an area you care about, please look at the repository, read the plan, challenge our assumptions, and tell us where you would like to help.

⭐ GitHub: https://github.com/MSKazemi/yazses

👁️ Hands-free epic: https://github.com/MSKazemi/yazses/issues/102

🏗️ Current eye-control planning PR: https://github.com/MSKazemi/yazses/pull/413

Developers, accessibility users, researchers, testers and documentation contributors are all welcome.

IDKMesh: What if AI agents had to prove their work?

Mohsen Seyedkazemi Ardebili — Mon, 21 Sep 2026 19:15:11 +0000

A few days ago I wrote about one result from IDKMesh: a panel of 25 verifiers that, after measuring their shared errors, was effectively worth only one independent verifier.

That experiment is interesting, but it starts in the middle of the story.

So this post is the simpler version:

What is IDKMesh, why am I building it, and how is it supposed to work?

The problem

AI agents are getting very good at producing things.

They can write code, edit files, call tools, generate tests, open pull requests, and sometimes operate infrastructure.

But there is a basic problem:

An agent saying “I finished the task” is not the same as evidence that the task was done correctly.

If we scale from one agent to ten agents, or one hundred agents, generation becomes faster.

Verification can become the bottleneck.

And if all of those agents or reviewers make similar mistakes, adding more of them may only give us more confidence, not more truth.

That is the problem IDKMesh is exploring.

What is IDKMesh?

IDKMesh is an open-source research and engineering project about coordinating:

humans,
AI agents,
software tools,
verifiers,
and different kinds of compute

around uncertain work.

The name comes from a simple idea:

I don’t know. You don’t know. Together, the mesh can discover, build, verify, and learn.

For me, the most important word is not “mesh.”

It is verify.

IDKMesh tries to separate the thing that does the work from the thing that decides whether the work should be trusted.

A simple example

Imagine I give an AI agent this task:

Fix a bug in a Python project.

A normal agent workflow might look like this:

Task
  ↓
AI agent
  ↓
Code change
  ↓
“Done”

That is useful, but the same system that created the answer is also telling us the answer is good.

IDKMesh is aiming for something more like this:

Human goal
    ↓
Bounded Work Unit
    ↓
One or more replaceable workers
    ↓
Candidate results
    ↓
Independent verification
    ↓
Recorded evidence
    ↓
Human / governance decision

The worker can propose.

The verifier can check.

The evidence can be inspected later.

And the final authority stays separate.

Worker success != acceptance.

That small rule changes a lot.

How it works

At a high level, IDKMesh uses a few simple building blocks.

1. Give the worker a bounded job

Instead of giving an agent unlimited authority over a project, work is described as a Work Unit.

The task says what needs to be done, what the boundaries are, and what security constraints apply.

2. Let workers produce candidates

A worker is allowed to try.

There can be multiple attempts.

The first answer does not need to become the final answer.

Workers are replaceable. Their output is a candidate.

3. Verify separately

A verifier should not simply trust the worker’s own completion claim.

Verification has its own plan and produces its own result.

This is where tests, independent reviewers, policy checks, or other evidence can enter.

4. Keep the evidence

IDKMesh treats provenance and verification results as real artifacts, not temporary chat messages.

The goal is to be able to ask:

What was the task?
Who or what produced this result?
What checked it?
Which evidence supported the decision?
Can we replay or inspect it later?

5. Keep the final decision explicit

A worker does not get merge authority just because it says “success.”

A verifier recommendation is also not automatically the final decision.

The integration step stays explicit.

[Place the IDKMesh explainer image here.]

What can you actually use today?

This part is important because I do not want to describe research as a finished product.

The full Verified Swarm Runner is not yet a production-ready multi-agent platform.

The repository is still a research and engineering foundation.

But one useful tool is already available: idkmesh gate-audit.

It takes verdicts from a review panel you already have and asks a practical question:

How many independent votes is this panel actually worth?

The repository also contains experiments, schemas, validators, simulations, interoperability work, and pieces of the future runner.

Try it

If you have Python 3.11+:

git clone https://github.com/MSKazemi/idkmesh
cd idkmesh

python -m venv .venv
source .venv/bin/activate

pip install .
idkmesh gate-audit examples/gate-audit/panel-votes.example.json --pretty

You can also run the repository demo:

python scripts/demo.py

No model API key is required for that demo.

What I want IDKMesh to become

The long-term idea is bigger than a review tool.

I want to explore whether large groups of humans and AI agents can work on real problems without making trust an afterthought.

That means learning how to:

divide work into bounded tasks,
run multiple independent attempts,
use different workers and tools,
measure whether verification is actually independent,
keep reproducible evidence,
learn from failures,
and scale without giving autonomous workers unlimited authority.

I do not know yet how far this model can scale.

That uncertainty is part of the project.

The repository is designed to test those questions rather than pretend they are already solved.

Why open source?

Because a system about verification should itself be inspectable.

If IDKMesh makes a claim, I want the experiment, code, result, or limitation to be visible.

And I especially want other people to find the assumptions that are wrong.

If you are interested in AI agents, verification, distributed systems, CI, developer tooling, or human-in-the-loop systems, take a look at MSKazemi/idkmesh on GitHub.

You do not need to understand the whole project to contribute.

Even showing where the newcomer path is confusing is useful evidence.

This article was prepared with AI assistance and manually reviewed against the current IDKMesh repository before publication.

Suggested DEV tags: #ai #opensource #python #agents

Our linter's "safe" autofix would have silently disabled RBAC

Mohsen Seyedkazemi Ardebili — Sun, 20 Sep 2026 21:54:58 +0000

KubeIntellect is an AI agent that runs kubectl against a live cluster, so its tools carry a role check and a human-approval gate. Both depend on one thing: the tool actually receiving the run config the graph injects. This is the parameter that receives it.

config: Annotated[RunnableConfig, InjectedToolArg] = None,  # type: ignore[assignment]

That line is wrong in every way a reviewer is trained to notice. The default is None, but the annotation does not say | None. mypy complains, which is why there is a type: ignore sitting on it. Ruff wants to rewrite the Optional[...] spelling of it. Every instinct says clean this up.

Cleaning it up disables role-based access control.

Why the annotation is load-bearing

LangChain finds the parameter to inject by walking the type hints and comparing with is:

for name, type_ in type_hints.items():
    if type_ is RunnableConfig:
        return name
return None

That is an identity comparison against one exact class object. RunnableConfig | None is a UnionType, not that object. It does not match, so no parameter is selected, so nothing is injected.

Three functions, run against langchain-core 1.6.2:

def bare(cmd: str, config: Annotated[RunnableConfig, InjectedToolArg] = None): ...
def widened(cmd: str, config: Annotated[RunnableConfig | None, InjectedToolArg] = None): ...
def optional_form(cmd: str, config: Annotated[Optional[RunnableConfig], InjectedToolArg] = None): ...

bare           -> injected param: 'config'
widened        -> injected param: None
optional_form  -> injected param: None

No error. No warning. The tool still runs. It just receives config=None forever.

What is actually lost

The caller's role comes off that config, and the fallback is the problem:

user_role = "admin"
if config:
    user_role = (config.get("configurable") or {}).get("user_role", "admin")

With the config gone, config is falsy and every call executes as admin. A readonly API key stops being read-only. The check that returns [Permission Denied] Your API key has read-only access is still there, still covered by its unit tests, still passing — and it never fires, because the role it compares against is no longer the caller's role.

To be precise about the other half, since overstating this would be easy: the human-approval gate does not break the same way. hitl_bypass also comes off the config and defaults to False, so losing the config makes the tool prompt for approval more often, not less. The RBAC default is the one that fails open.

The part that makes it a trap rather than a bug

Nobody has to be careless to introduce this. The tooling volunteers it.

$ ruff check --select UP045 probe.py
UP045 [*] Use `X | None` for type annotations
 --> probe.py:5:35
help: Convert to `X | None`
[*] 1 fixable with the `--fix` option.

The [*] means ruff classifies that rewrite as a safe fix. Not --unsafe-fixes. Plain ruff check --fix — the command people run without reading the diff — converts a working authorization boundary into a no-op.

A behavioral test will not save you either. The tools most likely to get "cleaned up" are the ones that never read config at all: they pass every test they have while silently receiving None. We found exactly that shape in four of our own read verbs. Harmless there, because those verbs make no authorization decision — but it is the same defect, one file away from a place where it matters.

What we did instead of a comment

There is a comment on the line. Comments do not fail CI.

The guard is a test that asserts the annotation itself. It scans every config: Annotated[..., InjectedToolArg] parameter in the source and fails if any is not bare RunnableConfig. Alongside it are two dynamic canaries that build a real tool with each spelling and assert, against whatever langchain version is actually installed, that the required form is injected and the forbidden form is not — so the day the library changes its matching rule, a test says so instead of production.

There is also a test asserting the scanner finds the known sites, because a regex that matched nothing would make every other assertion in the file vacuously true.

The general version

When a framework dispatches on type identity, your annotation is not documentation. It is runtime configuration written in the type language — and anything that "improves" your types can change behavior: a linter, a type checker, an IDE quick-fix, or an agent asked to clean up implicit Optional.

If you have a line like that, the fix is not a louder comment. It is a test that fails when someone improves it.

Code: https://github.com/MSKazemi/kubeintellect
The guard: v4/tests/test_injected_config_invariant.py

A 25-verifier panel measured an effective size of 1.00

Mohsen Seyedkazemi Ardebili — Sun, 20 Sep 2026 21:48:15 +0000

Generation got cheap. Trustworthy review did not.

So we add reviewers. More eyes on the PR, more verifiers in the gate, a panel of LLM judges instead of one. The assumption underneath is that each additional reviewer adds independent evidence.

That assumption is measurable. I measured it, and it did not hold.

What IDKMesh is

IDKMesh is an open-source research project (Apache-2.0, Python 3.11+) asking how humans, AI agents, tools, and heterogeneous compute can coordinate on uncertain goals and turn proposals into verified useful work.

It is a research preview, not production software, and the repository is deliberately conservative about what it claims: every number below traces to a committed experiment record you can re-run.

The thesis in one line: reviewer count is not independent evidence count.

How it works

The coordination model treats generation as cheap and verification as the scarce resource:

Work arrives as a bounded Work Unit that must declare its security bounds.
Replaceable workers attempt it. Multiple attempts are expected; candidates are disposable.
A separate, verifier-owned evaluation plan judges those candidates. Worker completion is not acceptance.
Results become reproducible evidence - result manifests, verification results, provenance digests.
Integration is an explicit decision gated on that evidence, not on a green impression.

The bundled demo makes the boundary concrete: it runs the real validators against committed fixtures and deliberately rejects four invalid ones - including a task with no security contract, and a worker result that accepts itself.

Measuring a gate

idkmesh gate-audit takes verdicts you have already collected and reports what the panel is actually worth. Here is the bundled example:

{
  "schema": "gate-audit-report-v0.1",
  "gate_id": "example-five-verifier-gate",
  "evidence_class": "synthetic",
  "inputs": { "candidates": 15, "verifiers": 5, "known_good": 8, "known_bad": 4 },
  "panel": {
    "nominal_votes": 5,
    "mean_verifier_accuracy": 0.8,
    "mean_pairwise_error_correlation": 0.0916,
    "effective_votes": 1.6944,
    "heuristic_n_eff": 3.6588
  },
  "probes": { "total": 3, "breached": 2, "breach_rate": 0.667 },
  "warnings": ["2/3 seeded known-bad probes were accepted by the panel"]
}

Read the third key before the interesting one: "evidence_class": "synthetic". Those five reviewers are invented, and 1.69 is a demonstration of the arithmetic, not a measurement of anything real. The project keeps a hard line between synthetic demonstration and observed evidence - so here is the observed side.

The observed result

Experiment E017 built a panel where every verifier is a program, not a model: a partial test oracle that draws inputs from one named region of a problem's input domain (tiny, small, large, extreme, duplicate) and accepts a candidate only if it matches a reference implementation on all of them.

5 regions x 5 seeds = 25 verifiers, run over a 72-candidate corpus whose ground truth comes from executing hidden tests. Every verifier's Youden J is significantly positive after Bonferroni correction - mean accuracy 0.7956. So the panel genuinely works, individually.

Error correlation between them:

same region (declared dependent)     mean rho = +0.8924
diff region (declared independent)   mean rho = +0.5263
all pairs                            mean rho = +0.5873

Verifiers that share no declared attribute still share 53% of their errors. A metadata group boundary is not an independence boundary.

Then the part that matters:

25-verifier majority error : 0.2083
single verifier            : 0.2044
measured effective size    : 1.00  (of 25 nominal)
N/(1+(N-1)rho) heuristic   : 1.66

The panel was worth no more than one of its members. Twenty-five nominal votes, an effective size of 1.00, and the standard correlation correction still overstated it by 1.66x.

The whole measurement ran in about 5 seconds on one laptop.

Why the usual correction doesn't rescue this

The familiar fix is to discount for correlation with N_eff = N/(1+(N-1)rho). Experiment E015 tested that heuristic across a parameter grid and found it exact at rho=0 and rho=1, wrong in between, and - importantly - the sign of its error is not fixed.

It is conservative where verifiers are weak, which is where conservatism is cheap. It is optimistic where verifiers are accurate and share modest dependence, which is exactly the regime you care about. At p=0.90, rho=0.125 the measured effective size saturates at 4.60 against a heuristic asymptote of 8.00 - and where an independent 9-verifier panel would deliver balanced error 0.000891, the real panel delivers 0.0125. Fourteen times worse.

What this does not claim

Being precise about scope, because it is easy to over-read:

No AI review panel has been measured in this repository. E017's verifiers are programs. Whether LLM reviewers exhibit the same correlation structure is an open question - and the one I most want data on.
It is a research preview. Not production software.
It is not on PyPI yet, so installation is from a clone.

Try it

git clone https://github.com/MSKazemi/idkmesh && cd idkmesh
python -m venv .venv && source .venv/bin/activate
python -m pip install -r requirements-phase0.txt
python scripts/demo.py

No model account or API key needed.

Repository: https://github.com/MSKazemi/idkmesh

If you have verdict logs from a real review gate - human reviewers, LLM judges, or CI checks - pointing gate-audit at them is the experiment I would most like to see someone else run. Especially if it disagrees with the above.

I recorded my Kubernetes AI agent failing, on purpose

Mohsen Seyedkazemi Ardebili — Sun, 13 Sep 2026 00:22:41 +0000

Most demos of AI-for-infrastructure tools show a clean run. I think that is exactly backwards, and I want to explain why by walking through the thirty seconds of my own demo that a normal product video would have cut.

The scene

A deployment is crash-looping. The agent has already diagnosed it. I ask it to restart the deployment.

It stops and asks for approval. I approve. The restart runs, and the command succeeds.

Then I ask the follow-up question: did the restart change anything?

No. The pods fail with the same error. A restart was never going to supply a missing environment variable. The agent re-reads the pods, re-reads the events, and names the same root cause it found at the very beginning: DATABASE_URL is not set, so the container exits 1.

The restart was a reasonable thing to try and the wrong thing to fix it, and the system is the one saying so.

Why that scene is the product

The worst failure for an incident-response tool is not being unhelpful. It is emitting something that looks like a real diagnosis and is not. At 3am a confident wrong answer costs more than no answer, because it sends a tired human down a wrong path with false authority.

So the design follows from that.

The approval gate is at the tool boundary, not in the prompt. A guardrail written into a system prompt is a suggestion, and models can be argued out of suggestions. Instead every mutating operation passes through one chokepoint that returns exactly three answers: do it, ask a human, or refuse. The model does not get a vote, so there is nothing to talk around.

Detectors are compiled predicates, not model calls. They are always on, they run on every observation, and they cost zero tokens. The LLM is only invoked once a detector actually fires. Watching your cluster is free; thinking about it is the expensive part, so it happens last.

Every decision is appended to a hash-chained log. A run can be replayed afterwards instead of remembered. If you are going to let software touch production, "what exactly did it do, and why" has to be answerable after the fact.

Roles are real. readonly, operator, admin and superadmin, enforced per key.

What it reads

kubectl for cluster state, Prometheus for metrics via PromQL, and Loki for logs via LogQL. It answers in plain English and quotes the evidence it actually read, so you can check it rather than trust it.

The video

Eight minutes, every terminal scene a verbatim recording against a live cluster. Nothing typed by hand, nothing reconstructed. The approval-gate segment starts at 2:27.

Try it

In your browser, nothing to install: https://kubeintellect.com/demo
pip install kubeintellect - AGPL-3.0, self-hosted, bring your own LLM provider
Code: https://github.com/MSKazemi/kubeintellect

The v1 architecture is written up in the Journal of Grid Computing (https://doi.org/10.1007/s10723-026-09837-6), with a preprint at https://arxiv.org/abs/2509.02449. The repo is several generations past that now.

If you run Kubernetes in production, the thing I most want to hear is which failure you would throw at it that I have not handled.

Offline voice dictation on Linux, without the cloud

Mohsen Seyedkazemi Ardebili — Mon, 22 Jun 2026 19:49:15 +0000

Offline voice dictation on Linux, without the cloud

Voice dictation is incredibly useful, but most people only meet it through cloud services: Google, Apple, Microsoft, or commercial tools that send audio away from your machine.

That is convenient, but it is not always ideal.

Sometimes you want dictation that works locally. Sometimes you are writing code, notes, private messages, medical text, research ideas, or internal company material. Sometimes you simply do not want every voice input to depend on an internet connection, an API key, or a subscription.

That is why I built YazSes.

YazSes is an open-source, offline voice-dictation tool for Linux. You hold a key, speak, release, and your words are transcribed locally with faster-whisper and typed into the focused app.

No cloud.
No API key.
No subscription.
Audio stays on your machine.

Repo: https://github.com/MSKazemi/yazses
Site: https://mskazemi.github.io/yazses/

The problem: most dictation is cloud-first

Voice typing has become common, but the default experience is usually cloud-based.

For many users, that is fine. For others, it is a problem:

You may not want private speech sent to a third-party service.
You may want dictation that keeps working offline.
You may want a tool that is scriptable, inspectable, and open source.
You may want voice input for Linux, terminals, editors, and custom workflows.

Linux users especially often have fewer polished dictation options than users on macOS or Windows. And for developers, accessibility users, and privacy-conscious users, “just use the cloud dictation built into something else” is not always enough.

What YazSes does

YazSes is designed around a simple workflow:

Hold a key.
Speak.
Release.
The text appears in the app you are using.

The transcription runs locally using faster-whisper. The output is then inserted into the currently focused app, so it can work with editors, terminals, browsers, chat apps, notes, and other everyday tools.

The goal is not to build a big AI assistant. YazSes is intentionally smaller and more predictable:

It is offline dictation plus voice commands. It is not an LLM agent.

That distinction matters. YazSes does not browse your files, reason over your project, or take autonomous actions. It listens when you trigger it, transcribes locally, and can map specific spoken commands to specific actions.

Install and quick setup

For Python users, the basic install is:

pipx install yazses

On Linux, you can also use Snap:

sudo snap install yazses

A typical first setup flow is:

yazses doctor yazses enroll yazses start

The idea is:

doctor checks your system setup.
enroll helps configure your voice/input workflow.
start runs the dictation daemon.

After that, you can hold the trigger key, speak, and release to type into the current app.

Voice commands and macros

Plain dictation is useful, but developers and power users often need more than text.

YazSes also supports voice commands for common editor and terminal workflows. For example, phrases can map to actions such as:

“undo that”
“save file”
“go to line 42”
“run the tests”
“rename this to user_id”

This is useful because voice input is not only about writing paragraphs. Sometimes you want to control repetitive editing actions without leaving your flow.

YazSes also supports macros and personal vocabulary, so the tool can become more useful for your own workflow over time.

How it works

At a high level, the pipeline looks like this:

Trigger key
   ↓
Record audio while held
   ↓
Voice activity / endpoint handling
   ↓
Local faster-whisper transcription
   ↓
Command grammar or plain text
   ↓
Type into the focused app

The important design choice is that the speech-to-text step happens locally. Your audio does not need to be uploaded to a cloud service to become text.

This makes YazSes useful for:

private notes
coding sessions
terminal workflows
accessibility experiments
offline environments
privacy-focused Linux setups

Limitations

YazSes is still evolving, and I want to be honest about the current scope.

First, YazSes is Linux-first right now. The repository also contains macOS and Windows backends/install guides, but those builds are still more experimental. I would especially welcome testers on macOS and Windows.

Second, Linux input behavior can depend on your desktop environment. X11 and Wayland can behave differently, especially around global hotkeys and text injection.

Third, YazSes is not an LLM agent. It will not plan tasks, browse your repository, or make decisions for you. It is a local dictation and command tool.

Fourth, accuracy depends on your microphone, environment, model choice, accent, and vocabulary. The goal is to make the setup practical and tunable, but speech recognition is never perfect for everyone out of the box.

Why I made it open source

I wanted a tool that was useful, inspectable, and privacy-friendly.

Voice input is too important to be locked behind cloud-only systems. It can help with productivity, accessibility, fatigue, coding, writing, and everyday computer use.

For me, the ideal version of this tool is:

simple enough to trust
local by default
useful on Linux
friendly to developers
helpful for accessibility users
extensible with commands and macros

That is the direction I am trying to take YazSes.

Try it

Repository:

https://github.com/MSKazemi/yazses

Project site:

https://mskazemi.github.io/yazses/

Install:

pipx install yazses

Or on Linux with Snap:

sudo snap install yazses

I would really appreciate feedback, especially on:

transcription accuracy
setup problems
Linux desktop compatibility
X11 vs Wayland behavior
useful voice commands
accessibility use cases
macOS and Windows testing

If the project is useful to you, a GitHub star, issue, or test report would help a lot.

DEV Community: Mohsen Seyedkazemi Ardebili

Find where two AI agent runs diverged

What you need

The scenario

Step 1: start the mock model

Step 2: capture the first run

Step 3: capture the second run

Step 4: diff the two runs

How to read it

Step 5: use it as a CI gate

What this does not do

I got tired of typing, so I built a free, offline voice-typing tool (open source, contributors wanted)

Install

Why offline?

Links

Want to contribute? Here is where you can help in 15 minutes

Try it, then tell me

AI Agents Need More Than Logs: Why I Built NovaFabric

Logs are useful, but logs are not evidence

Think of an AI run as an artifact

Five verbs explain most of NovaFabric

1. Capture

2. Seal

3. Replay

4. Diff

5. Audit

Why not just use OpenTelemetry?

What about secrets?

What did the research evaluation find?

An unexpected lesson

NovaFabric today

The bigger idea

Try it

YazSes

Help Us Build an Open, Offline Hands-Free Desktop

First: this is not “perfect eye tracking with a laptop webcam”

Some gaze functionality already exists

Glance-Type gaze routing

Gaze + speech deixis

Other pieces already exist — but are not complete runtime features

Implicit gaze calibration

Head-Pointer is another example

Face gestures should become switches — not direct actions

One camera, not three competing camera loops

Privacy needs to be part of the architecture

Public GitHub QA is not automatically research participation

“It worked on my laptop” is not enough

We also want to explore semantic grounding

Where are we today?

We are looking for contributors

The rule is simple

You will also be able to help without writing code

Accessibility experience is as valuable as code

How to get involved right now

What I hope we can build

IDKMesh: What if AI agents had to prove their work?

The problem

What is IDKMesh?

A simple example

How it works

1. Give the worker a bounded job

2. Let workers produce candidates

3. Verify separately

4. Keep the evidence

5. Keep the final decision explicit

What can you actually use today?

Try it

What I want IDKMesh to become

Why open source?

Our linter's "safe" autofix would have silently disabled RBAC

Why the annotation is load-bearing

What is actually lost

The part that makes it a trap rather than a bug

What we did instead of a comment

The general version

A 25-verifier panel measured an effective size of 1.00

What IDKMesh is

How it works

Measuring a gate

The observed result