Early · Opinionated · Open

en-quire

The governed document layer for agent systems.

Two sibling MCP servers with a shared reliability layer. en-quire handles structural edits across markdown, YAML, and JSONL. en-scribe handles plain text. Every write validated. Every change gated through git.

View on GitHub Read the paper

Install npx @nullproof-studio/en-quire

training/chat.jsonl · 10,000 records 
# Edit record 847 without touching 0–846 or 848+
jsonl.record_update(
  doc: "training/chat.jsonl",
  index: 847,
  set: { content: "..." },
  etag: "7f2c…a1d9"
)

✓ Record updated · validated on write
+ etag 8b4e…c5f3
⟳ proposed on branch: propose/agent-a/…
  • Addressable structure — heading, breadcrumb, positional index, YAML dot-path, glob
  • etag optimistic locking — stale writes fail loudly instead of silently clobbering
  • Git-native proposals — unprivileged callers propose; approval is a merge
  • RBAC scopes — per-caller path & permission control inside the MCP

The gap

Agent systems need to read, edit, and maintain living documents — SOPs, skill files, runbooks, memory, config, training data. Not one-shot generate them. The existing MCP options force a bad trade.

  • Filesystem MCPs are fast but unsafe. No etag, no validation, no audit. Two agents editing the same file clobber each other silently, and a single malformed JSONL append can corrupt a training dataset without warning.
  • Knowledge-graph MCPs impose opinionated schemas built for conversational memory, not operational documents. Markdown SOPs and YAML configs don't fit.
  • Search-only MCPs can read but not edit. Half the problem.
  • None of the above understand document structure, have RBAC, or support approval flows. Every caller is fully trusted.

That's fine when you're prototyping. It becomes a liability the moment real agents touch real documents — signed-off SOPs, training corpora, shared configs — under real governance.

Two sibling MCPs. One reliability layer.

en-quire is investigative. It understands document structure. Markdown sections, YAML keys, and JSONL records are addressable as typed sections. An agent asks for "Deployment > Rollback > 3.2 Plan" and gets exactly that — plus a context-aware diff on every write.

en-scribe is literal. It reads and edits plain-text files without interpretation: line ranges, literal anchors, append-at-EOF. No regex, no hidden semantics. The right tool for .txt, .log, and plain configs where structure is noise rather than signal.

Both build on the same primitives — etag optimistic locking, git-backed proposal workflows, unified diffs, RBAC, and write-time validation. Every write is gated. Every change has an audit trail in git history. No unprivileged caller writes directly — they propose.

What's inside

Structural editing

Sections across markdown, YAML, and JSONL

Every doc_* tool works uniformly across formats. Address sections by heading text, breadcrumb path (Procedures > Checks > Daily), positional index, YAML dot-path (services.api.port), or glob (2.*). JSONL records address by index.

etag locking

Stale-write protection, loud failure

Every read returns a content-hash etag. Writes validate before touching disk. A stale agent editing an old version fails with the current etag — rather than silently overwriting fresher work.

Git-native governance Designed · v0.3

Propose, review, merge

Unprivileged callers land writes on propose/<caller>/<path>/<ts> branches, not main. Approval is a merge. Rejection is branch deletion. Audit trail is commit history — no bespoke log format to maintain.

Write-time validation

Corrupt content never reaches disk

Malformed YAML blocked. Broken JSONL records rejected. Markdown with duplicate sibling headings or unbalanced code fences flagged. Every write runs through its format validator before landing.

RBAC with scopes Designed · v0.3

Per-caller path & permission control

Callers authenticate; each scope enumerates exact paths and exact permissions — read, write, propose, approve, search, admin, exec. Different agents, different capabilities, one MCP.

en-scribe In testing · release imminent

Plain-text editing, same reliability layer

Two primitives (text_find + text_replace_range) express any edit; sugar tools compose them for the common case and error clearly on ambiguity so agents don't get stuck. Same etag, same git, same RBAC.

Three sessions, two hosts, one protocol.

Three sessions, two hosts, one document — and the same governance throughout.

You could do this with each host's native file editor. You'd be trusting whichever vendor's approval model, audit semantics, and version control happen to ship in this release — and whatever ships next. en-quire is the layer where your governance lives. Approval gates, etag checking, git-native proposals, RBAC scopes apply to the document, not to the host. Your business process stops depending on a vendor's product roadmap.

Claude Desktop running an en-quire multi-section surgical edit with six changes tracked.
Claude Desktop · en-quire · Multi-section surgical edit · 6 changes tracked
Claude Desktop showing en-quire tool calls with collision detection between concurrent edits.
Claude Desktop · en-quire tool calls · Collision detection
My.NullProofStudio calling en-quire with routing and governance log entries.
My.NullProofStudio · en-quire tool call · Routing + governance log
Access control

Role-based data access — at the document layer

Each en-quire instance is configured with a defined data scope (e.g., en-quire-marketing reads /docs/marketing/*; en-quire-operations reads /docs/delivery/*). Granting an agent access to a particular instance grants it the data access associated with that role, enforced at en-quire's layer rather than the host's. This is RBAC for the data-access dimension specifically; cross-capability role composition (data access + tool capabilities + system permissions) lives at the host's tool grant layer where it belongs. en-quire ships the part of role-based access control that belongs to the document layer, and stays out of the parts that don't.

Scoping is at the folder/path level, not file-level. File-level ACL fails reliably at enterprise scale: it's error-prone, rarely maintained correctly, and creates audit confusion. Most production access control already operates at the data-scope dimension — what RBAC literature pairs with Client-Based Access Control. en-quire follows the model that experience teaches works.

Get started

1

Install

npx @nullproof-studio/en-quire

en-core and en-quire are live on npm now. en-scribe is in internal testing — public release imminent. Works with any MCP-compatible client — Claude Desktop, VS Code, or your own integration.

2

Configure roots & scopes

Define named document roots — each with its own git repo, permissions, and search index. Paths prefix by root (sops/, config/, training/). Define RBAC scopes per caller so agents that shouldn't write, don't.

3

Propose, review, merge

Agents read, search, and propose edits. doc_proposals_list / _diff / _approve / _reject are first-class MCP tools — approvers don't need git CLI skills. The git history is your audit trail.

View on GitHub Read the paper

Where we're at. en-quire is at v0.2 — early, opinionated, open. Shipped today on npm: structural editing across markdown, YAML, and JSONL; etag optimistic locking; write-time validation; full-text search. Architecture-complete, landing in v0.3: git-backed proposal workflows and RBAC scopes (the API surface is wired in; hardening in progress). en-scribe is in internal testing, publishing to npm and GitHub imminently. Not a claim of production-readiness — expect sharp edges and breaking changes while the API settles.