E-REW — Requirements Engineering Workbench

Engineering Intelligence. Verified Knowledge. Sustained Value.
Git-native requirements engineering 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. E-REW is built for the first kind.

Ejadah AI Labs

We are a startup, and these twelve areas are what we are focused on. E-REW 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

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 E-REW gives you

Your requirements are Markdown files with YAML frontmatter in your Git repository. Nothing else. Delete E-REW 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: this is a 30-day pilot

This build stops working 30 days after you first open it. Not a downgrade to a free tier — it stops, and asks you to install the current version.

That is deliberate, and it is the honest consequence of how early this is. E-REW collects no email address and has no registration, so there is no way for us to tell you when a better build exists. Expiry is the only message that reliably arrives. The 30 days start at first activation on your machine, are recorded locally, and are never written into your repository or sent anywhere.

Nothing you create is affected. Your requirements are Markdown files in your own Git repository. They are yours, they stay readable in any editor, and they are untouched by the pilot ending.

Registration is coming, and with it a licence that does not expire on a timer. Until then please treat this as an evaluation build — 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 E-REW 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.

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 — eleven engines

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

• 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; E-REW 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" — E-REW 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: E-REW 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

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.

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 REW: 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; 1,288 assertions across five suites on Node 20 and 22.

We are honest about the gap: E-REW 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.

License

Proprietary. See LICENSE.

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