Code Intelligence Engine for Codebases | Dweve Reed

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Knowledge governance built on Reed-parsed atoms.

Verified runtime with BLAKE3 chain integrity.

Proofs and certificates that pair with Reed roots.

Correctly rounded math under the parsing layer.

Explore what Reed’s structural reading records before choosing an adoption route.

regular tokens via DFA, the rest via scanners

BLAKE3 binds parse to input, grammar, config.

Shared packed forest. All valid parses retained.

Cascades SLR to GLR to GLL, fastest to most general.

UTF-8 lexer. Trivia preserved. Error recovery.

Audit means rebuilding. Expensive and fragile.

Parse tree lives in RAM and dies with the process.

Code, configuration, documents and DSLs.

When the question comes, the kept receipt answers it without a rebuild.

Installs on the servers you own, then the proof simply starts accumulating.

A and a public repo make for a short, clean review.

For the most sensitive work, Reed runs with no network at all.

Pinned to a member state you choose. Nothing crosses a border you did not approve.

Inside your building, behind your firewall. The work never leaves the room.

Nothing was kept at the time, so there is nothing to point to.

A fragile process that still ends in a result nobody fully trusts.

Confirming the source means rebuilding the whole codebase.

The answer is a promise, not something anyone can verify.

Once Reed publishes in the third round, holding the source outright means a supplier change never strands your tooling.

A proof receipt replies to the auditor without a rebuild.

Runs on a standard CPU. No GPU fleet to procure or wait on.

Runs inside the existing toolchain with no external service or per-seat meter. The budget is integration and operation, not recurring access.

The source is yours to hold. If a supplier relationship ends, your tooling does not.

Repository history and build instructions stay visible to technical reviewers.

Inspect the parser, reproduce the build and retain every certificate it emits.

No. Reed runs inside the product and does not depend on an external Reed account.

No. It reads right where you are and phones nothing home.

No. It comes built in and works on its own.

No. It is free and stays free, with nothing to buy later.

The app does not depend on a Reed account or remote service to keep reading your files.

Change one word and the little receipt stops matching.

Ask the same thing twice and the answer does not change.

Your words come back the way you left them, years later.

A computer far away reads the same file and gets the same stamp.

If a single word changes later, the stamp no longer matches.

A small stamp shows it read exactly that file and nothing else.

Reed opens your document and understands what is inside it.

Adopting Reed is not an engineering programme. It follows the review path you already use through procurement, IT and compliance, and nobody has to write code. This is the route from first approval to the day Reed answers an auditor.

The last question is where the data lives. Reed has no home server of its own and reaches out to nothing while it works. It runs on your own machines, in an EU data centre you choose, or completely offline. Your data stays under European rules and never crosses a border you did not approve.

The whole reason Reed exists is one question an auditor will eventually ask: was this built from approved source, and can you prove it. Today the honest answer is "trust us". Reed turns that into a piece of evidence anyone can check. Here is the same question, answered the old way and the Reed way.

Two questions decide whether a tool is worth adopting: which recurring costs does it remove, and which exposures does it reduce? Reed answers both. The left side shows the savings; the right shows the risks reduced. No code or jargon, just a case you can take to an approval meeting.

Start with the question procurement asks first: what enters the estate and who controls it. Reed runs inside your own toolchain, keeps receipts with the results and introduces no service dependency.

It is fair to be careful with anything new on a computer. So here are the honest questions a sensible person asks, with plain answers you can trust. Open any one to read more.

Most of the time you will never know Reed is there. But it is doing small, useful things underneath, the kind of things that save you a headache later. Here are a few everyday worries it quietly takes care of.

You can meet Reed every day without noticing it. It sits inside ordinary products such as a writing tool, a website form or a helper that answers questions, and quietly performs one bounded task. These are a few of those moments.

Here is the part that quietly matters. Reed reads the very same file the very same way, whether it runs on your computer at home or on a computer in another country. The answer does not change just because the machine did. No surprises, no different result on a different day.

Think of Reed as a careful reader that works for the computer. When an app needs to open a document, a form, or its own settings, Reed is the part that reads it properly and understands what is inside. You never touch it. It just makes sure your things open the way they should.

SLR drives a fast table-driven path, GLL stays general at polynomial worst-case time, and incremental reparse touches only the edited subtree. SIMD structural scanning runs at gigabytes per second on the CPU you already own.

Reed ships as a Rust library, a CLI binary, a Language Server, and a stable C ABI. The same parser, the same hashes, the same RQL, wherever your tooling lives.

Reed Query Language describes tree patterns in concise notation. The compiler lowers RQL to a 20-opcode bytecode and a backtracking VM runs it across the parsed tree. Find imports, count calls, locate a regex inside a string literal.

Some tokens a regex cannot express: indentation, heredocs, nested comments, raw strings. Reed ships eight built-in external scanners and lets you register your own with one grammar directive.

Reed is not one parser. It compiles a single RGS grammar into four engines, SLR, LALR, GLR, and GLL, and parse_auto cascades from the fastest to the most general. Then every node is hashed and the tree is sealed into a BLAKE3 certificate bound to input, grammar, and config.

Most parsers produce an AST and forget the source. Reproducing a build means re-parsing the entire codebase. Auditors asking "was this built from approved source?" have no answer, only a chain of trust.

Three commands: build the CLI from the workspace, parse your repo, read the certificate root. The BLAKE3 root of your source tree is in your terminal in seconds.

Reed turns every parsed codebase or configuration set into a stable, checkable record. Teams retain the source, parser contract and BLAKE3 root, so audit questions become evidence lookups instead of expensive rebuilds.

Reed works inside the apps you use. It opens documents and forms, understands their structure, and keeps a receipt so the same file is read the same way each time. You never need to set it up.

Reed parses source into a stable tree and seals the result with a BLAKE3 certificate root. Teams can query the structure as data and verify later that the tree still corresponds to the same source and parser contract.

Reed is the local code-reading engine inside Dweve Fabric. It recognises the parts and relationships in structured text and keeps each part tied to its exact place, so the workspace can respond precisely and produce the same structure again when nothing has changed. Reed is published under Apache-2.0.

Workspace rules, settings and other structured text carry an order that software must understand. Reed identifies the named parts and their relationships, and keeps each one connected to the exact place it came from.

Fabric receives a structured result tied to the original text

Reed follows the same defined reading whenever Fabric handles unchanged structured text under unchanged conditions. The result does not drift between runs, and a change to the text or its conditions produces a different result.

Repeatable reading keeps the workspace consistent

Reed keeps the structure clear underneath

When you open workspace rules, change a setting or bring in structured text, Fabric handles the visible experience. Reed keeps the named parts, relationships and exact locations clear underneath, so Fabric can respond to the right part.

Reed identifies the exact place where structured text stops matching the form Fabric expects. That lets Fabric give a focused message about the affected part while keeping unchanged parts separate and visible.

Precise locations give Fabric a precise place to respond

You do not open Reed, operate it or choose its reading conditions. Dweve Fabric uses it behind the workspace and turns the returned structure and locations into the features and feedback you see.

Fabric can point to the affected part while keeping the rest in view

The text and reading conditions stayed the same

Fabric can turn this exact place into a useful message

Structured text handled by the workspace

Parts, relationships and exact locations