Sanad

Engineering Intelligence Workbench

Every claim, with its chain.
Git-native engineering intelligence, with evidence you can regenerate.

Part of the Ejadah Engineering Intelligence Platform, by Ejadah AI Labs.

A question has a deterministic answer. A prompt has an opinion. Sanad is built for the first kind.

Sanad — Arabic سند, the documented chain that makes a claim trustworthy.

Ejadah AI Labs

We are a startup, and these twelve areas are what we are focused on. Sanad is where they land first.

Five principles hold across every one of them, and they are architectural rules rather than slogans — each is enforced in code, and the sections below show where:

Evidence First · Single Source of Truth · Deterministic · Measurable · Reproducible

Our vision: engineering intent should never be lost, engineering knowledge should never be forgotten, and engineering reality should continuously align with engineering decisions.

Engineering organizations do not fail for lack of tools. They fail because knowledge fragments across code, requirements, architecture, models, tests, certification evidence, wikis, spreadsheets and the heads of individual engineers — none of which understand each other. As a programme runs, reality drifts from intent: architecture erodes, traceability breaks, documentation goes stale, and the reasoning behind decisions leaves with the people who made it.

We build the layer that keeps intent and reality aligned — continuously, with evidence, and without asking you to abandon the tools you already use. We do not replace your ALM, MBSE, SCM or CI. We connect them and answer questions none of them can answer alone.

The product family

Superseded. The single-product decision of 2026-08-12 replaced this seven-product family with one product, Sanad, extended by capability packs. The table is kept rather than deleted so the change of direction stays visible. Read the rows below as disciplines Sanad covers or will cover, not as separate products.

Each Engineering Workbench covers one discipline. Each is a complete product on its own; together they compose through your Git repository — never by calling each other, so one working without the others is normal, not degraded.

We build the next workbench when a real user is waiting for it — not before. We would rather ship one product that is genuinely indispensable than seven that are nearly useful.

What Sanad gives you

Your requirements are Markdown files with YAML frontmatter in your Git repository. Nothing else. Delete Sanad tomorrow and you still have readable requirements, full history, and every review that ever happened.

That last line is the one that matters for certification. A report that depends on who ran it is not evidence.

Before you install: what this build is

Each build runs for 45 days from its release date, then asks you to update. Sanad is a prototype, and while it is one we would rather everybody were on a recent build than on whatever they installed six months ago. So every released version stops after 45 days, counted from the day it was released — not from the day you installed it, so everyone on a given version stops on the same day. The version you are running names its own date: you will see a non-blocking notice on each of the last seven days, and the message that stops it names the date, the reason and where the newer build is. Updating is the whole of the fix, and the newer build always does more than the one it replaces.

This is a prototype-phase measure, not the licensing model. It goes away when the licence server ships with the first stable release; there is no account, no activation call and nothing to register — it is a date in the build.

Nothing you create is affected by that. Requirements are your files in your repository; an expired build stops running, and changes nothing you wrote.

Nothing you create is locked in. Your requirements are Markdown files with YAML frontmatter in your own Git repository. They are yours, they stay readable in any text editor, and they remain useful if you stop using Sanad tomorrow. Sanad reads and writes your repository and nothing else — no account, no telemetry, no upload.

It is early, and the honest framing is evaluation. Every analysis engine runs in this build. What is not yet proven is long production use across many repositories, so treat findings as a well-evidenced second opinion rather than a verdict — and tell us what is wrong with it in the support repository.

Features — available in this release

Six of the twelve focus areas above ship in Sanad today: Requirements Intelligence, Knowledge Graph, Drift Detection, Impact Analysis, Metrics & Dashboards, and AI Assistant Agents — with Compliance & Governance partly delivered through rule packs and criticality bands.

The capabilities, and how far along each one is

Sanad is one product with capability packs. They are not at the same level of maturity, and rather than let you find that out yourself, the product says so wherever you meet them — in setup, in the explorer's capability switcher, and on the lane itself.

Nothing marked Work in progress is switched off, hidden or crippled. It runs, you can use it today, and it tells you what it is. Treat what those two report as a well-evidenced second opinion, and treat Requirements as the part we will stand behind.

Authoring

• Requirements explorer, grouped by type, in declaration order
• New Requirement — allocates the next ID, creates the file, opens it, cursor placed
• Ctrl+click navigation between requirements; hover for title, type and status
• ID completion that offers only real requirements, correct parent types first
• Safe delete — names every requirement that will be left with a broken link before you confirm, and never edits a file you did not open
• No recursive delete anywhere, not even behind a confirmation
• Only fields you actually changed are re-serialised — untouched sections stay byte-identical, so git diff shows one section, not the whole file

Your vocabulary, not ours

• Templates are prototypical requirements written in Markdown — to author one, paste in a good requirement and blank the values
• Fields carry roles. Call your parent link satisfies and your criticality dal, and every analysis still works, with no configuration and no release from us
• An undeclared role disables the analysis that needs it — silence with a stated reason, never a guessed number

Analysis — thirteen engines

Validation · Quality · Traceability · Structure · Verification · Implementation · Safety · Security · Architecture · Consistency · Interface · Conformance · Impact

• The four that belong to the two work-in-progress capabilities — Implementation, Architecture and Conformance (Software), Verification — run like the rest and are marked as work in progress wherever they report
• Findings appear as squiggles and in the Problems panel, on the exact words they name
• Findings derived from prose render as candidates for human judgement, never as fact
• Full pass under 160 ms at 5,000 requirements
• Verification and implementation independence is enforced by the type system — each engine is handed a graph that physically lacks the other's data, so independence is structural rather than a promise

Drift — code against requirements

• Commit a symbol index; Sanad compares what requirements claim against what code says
• implements-disputed, implements-unacknowledged, missing-symbol, unindexed-symbol
• Declared index coverage separates "the code was removed" from "nobody looked there" — Sanad will not report a claim as broken when it was merely unverified

Governance and evidence

• Rule packs — change severities, silence checks, bind strictness to criticality, in a YAML file committed to your repository. Data, never code: Sanad does not execute anything found inside a repository
• Criticality bands (DAL / ASIL / SIL) with inheritance, resolved once
• Deterministic reports — regenerate byte-identically at a commit
• Visual dashboard — gauges and bars, every number traceable to a metric

Analysis in CI — the headless gate

• The same engines, rule pack and roles run from a plain shell: erew [path] --gate error
• Exit codes a build can gate on: 0 pass, 1 findings at or above the gate, 2 usage error
• Findings, JSON evidence and reports on stdout, byte-identical at a commit; the human summary and timings on stderr, where they cannot pollute a diff
• A finding inferred from prose presents at most as a warning, so the default error gate never fails on a candidate; stricter gates (--gate warning|info) count candidates like any other finding
• Copy-paste GitHub Actions recipe in the User Guide

AI — optional, and subordinate

• Off unless you supply a key; the product is fully functional without it
• AI may propose; only deterministic analysis attests — AI output never enters reproducible evidence
• Output arrives as ordinary Git edits you accept or reject

Planned — premium and future

Roadmap, not commitments. Ordered by how often engineers ask for them. The first two rows are in your hands today and are the ones still being proven.

Getting started

1. Install the extension
2. Open a folder with .ejadah/rew/templates/ and requirements/
3. Right-click a type → New Requirement
4. Run Sanad: Run Analysis

Read the User Guide — 15 minutes, and section 4 on roles is the one that makes everything else make sense.

Support

Those are targets we hold ourselves to, and they mean a substantive response — a fix, a workaround, or a clear statement of what we found. Blocking safety-critical work? Say so in the first line; it changes our ordering.

Full policy: SUPPORT.md.

Status

Pre-1.0. Analysis, authoring, reports and dashboards are complete and tested; Every suite green on Node 20 and 22, with the total assertion count held by a ratchet that may only rise — so a suite quietly shrinking fails the build, and adding tests never does.

We are honest about the gap: Sanad is verified — tested, deterministic, gated — and not yet validated by long production use across many organizations. If you are an early user, you will have unusual influence over what gets built. That is the trade, and we would rather state it than let you discover it.

That gap is not the same width everywhere, which is why the capability table above exists. Requirements is where we have made real progress and it is what we ask to be judged on. Software and Verification are work in progress: they ship in this release, they run, and we have not finished testing them ourselves. You will see that said on the lane, in setup and in the capability switcher — not only here.

License

Proprietary. See LICENSE.

Ejadah AI Labs — engineering standards and principles at ejadah-foundation.