Engineering CommonsOpen source by EnWithAI

Evidence for every change your team, and your AI agents, ship.

AI has made writing code cheap. It has not made knowing cheap. Engineering Commons is a family of open-source checks that turn opinions about your specs, changes, architecture, delivery and launch readiness into evidence.

npx @enwithai/commons-check --stage PRE_LAUNCH
Explore the five checksStart in five minutes
  • MIT licensed
  • Runs offline
  • No account, token or telemetry
  • Never executes your code
  • No AI model in the loop
Public demo

Verdict

NOT_READY

  • Secrets gateFailed
  • Open P0 findings8

What happens nextEach fix gets its own work packet, and a retest shows which fixes are verified and what regressed.

How every verdict is decided

  • Three pillars, never averagedCustomer · Technology · Trust
  • Failed hard gates force NOT_READYUnverified gates force INCONCLUSIVE
  • Untested is never passedReported as NOT_TESTED or BLOCKED, with the reason
  • The bar matches your stageSeven tiers, from CT-T0 to CT-T6

Output goes up. Confidence does not.

Specs are vaguer, pull requests are larger, architecture diagrams go stale faster, and “is it ready?” is still answered by opinion in a meeting.

  • The spec is done.

    Which requirements would a developer, or an agent, have to guess about?

  • It’s a small change.

    What depends on it, and which contracts break for consumers?

  • The architecture is documented.

    Does the model in git still describe the code beside it?

  • AI is making us faster.

    What did delivery measurably achieve, with denominators and sample sizes shown?

  • We’re ready to launch.

    Ready by which controls? And which ones were never tested at all?

Dashboards that collapse these into a single score hide exactly what matters. Engineering Commons does the opposite: every answer comes with its evidence, its limits, and an action for a named person.

Evidence over assertion.

Every finding in every tool carries one of three labels, and they are never blurred. Each points to path:line or the exact HTTP response, says where it came from, and names the action for a person.

  • Verified fact

    Proven statically: a file, a line, a commit, a parsed contract.

    What you do: act on it.

  • Hypothesis

    A reasoned signal that a person should confirm.

    What you do: review it.

  • Unknown

    Cannot be decided from static evidence, and the report says why.

    What you do: decide how to find out.

Honest by design

  • Untested is never passed. Anything a tool could not check is reported as NOT_TESTED or BLOCKED, with the reason, and coverage drops accordingly.
  • No opaque scores. No spec-quality score, risk percentage or architecture grade. Where Product Check scores, its three pillars stay separate, with coverage and confidence beside each.
  • No ranking of people. Outcome Check measures delivery, not developers. It never names or ranks individuals, and never claims AI caused a difference.

Safe to run anywhere

  • Offline and deterministic. Same input, same output, byte for byte. No network calls, API keys or telemetry.
  • Read, never run. Your repository is read as data. Nothing in it is executed, and no AI model is called.
  • Your data stays yours. Outcome Check reads exports you create and never calls GitHub. Product Check probes a deployed app only when you authorize it, with passive GET requests.
  • Open and permissive. MIT licensed, published on npm and GitHub under @enwithai, with CI on Node.js 22, 24 and 26.

One evidence chain.

Each check answers one question well. Together, every tool’s output becomes evidence for the next, ending in one product verdict and an engineering blueprint.

Markdown specsAny folder, or Spec Kit

1Spec CheckIs the spec buildable?also checks the as-built spec from ⑤

Git branchAgainst a base, like a PR

2Impact CheckWhat does a change affect?exports the module graph to ③

C4 or CALM modelOr none: derive one

3Architecture CheckDoes the model match the code?

PR and CI exportsFrom the GitHub CLI

4Outcome CheckWhat did the work deliver?

Operational evidenceOpenSLO, alert rules, OTel service graph, test results, npm audit

PR diff, claims, signed approvalsFor review and closure

5

Product Check

Reads every report beside it, plus your operational evidence.

CustomerTechnologyTrust

Verdict
READY, READY_WITH_CONDITIONS, NOT_READY or INCONCLUSIVE
Engineering blueprint
Prioritized fixes, work packets, a dashboard and a retest loop
Review and closure
Each finding verified, an AI reviewer’s claims included. A fix counts only after proof at the fix commit and signed human approval.
Release gate
GO, CONDITIONAL_GO, NO_GO or UNKNOWN

⑥ Blueprint CheckTakes ③’s as-built model, ②’s module graph and ⑤’s product surface, and draws the architecture dossier as Mermaid views. Its workspace.dsl goes back to ③ as the model it guards, with a staleness check.

Commons CheckRuns ① to ⑥ in one process, feeds each report into the next, and writes one SUMMARY.md. It reports ⑤’s recorded release gate; you run review and closure with Product Check itself.

FoundationCommons governance: a shared charter, attribution standard, SPDX licensing and review checklist keep every tool’s claims honest and consistent.

Five checks. Five questions.

The questions every engineering leader asks, each answered by one tool. Use one, or all five: each is MIT licensed, runs offline and stands on its own.

Spec Check

@enwithai/spec-checkv0.3.261110

When an AI agent builds from a vague spec, it does not ask. It guesses. Spec Check finds the exact lines a person or an agent would have to guess about, before any code is written.

Reads
Markdown specs, with first-class support for GitHub Spec Kit spec.md files.
Finds
Unresolved [NEEDS CLARIFICATION] markers and placeholders, TBD and TODO in requirements, vague terms such as “fast” with no number, success criteria with no measurable target, incomplete Given/When/Then scenarios, missing edge cases or non-functional constraints, and duplicate or dangling requirement IDs.
Opt in
A design-package profile checks decision records, SLO targets, security and AI-governance sections, and required documents such as an architecture model or runbook.
Delivers
A requirements inventory, every FR-, NFR- and SC- item with its findings, as Markdown, JSON or SARIF for code scanning.

Use it when reviewing a spec before sprint planning, gating agent-driven builds on spec quality, or auditing a design package before an architecture review.

Terminal

npx @enwithai/spec-check check                    # Spec Kit layout: specs/*/spec.md
npx @enwithai/spec-check check docs/requirements  # any Markdown folder

@enwithai/blueprint-checkv0.3.261110

⑥ Blueprint Check: what does the system actually look like?

Architecture diagrams are drawn once and trusted forever. Blueprint Check generates the as-built blueprint of your repository from what the other checks can prove, and tells you the moment it stops being true.

Terminal

npx @enwithai/blueprint-check generate  # writes architecture-blueprint/
npx @enwithai/blueprint-check check     # exit 4 when the blueprint is stale

Use it when onboarding engineers to an unfamiliar codebase, preparing an architecture review or due diligence, starting architecture-as-code without drawing the first model by hand, or keeping documentation honest in CI.

  • A blueprint people can read. Master plan, repository and deployable map, floor plan, data plumbing, API wiring, storage, site plan, deployment and per-container detail, as Mermaid diagrams in one dossier.
  • Every line on the drawing is evidenced. Each element and connector links to the file and line that proves it, labeled confirmed, corroborated or inferred. An SDK import is corroboration, not proof of a call.
  • Honest about its limits. Request flows, critical journeys, trust enforcement and operations need judgment, so they are marked blocked with what would resolve them, never invented. Coverage is counted, never scored.
  • Feeds Architecture Check. Its Structurizr model becomes the declared model that Architecture Check guards on every pull request.
  • Stays current. check re-hashes every cited line, re-derives the model, and fails when the blueprint is stale.
@enwithai/commons-check · v0.3.261110

All six. One command. One summary.

Commons Check runs the five checks and Blueprint Check on your repository in order, in one process, feeds each report into the next, draws the architecture blueprint, and writes one summary a head of engineering can read.

npx @enwithai/commons-check --stage LAUNCH_GATE --base main --prs prs.jsonl --runs runs.json

You get, in commons-report/

  • Every tool’s full report, and Product Check’s dashboard.
  • The architecture blueprint, in commons-report/blueprint/ (--skip blueprint skips it).
  • SUMMARY.md: each step’s status and top findings at path:line, Product Check’s verdict and pillar scores, every control that could not be tested and why, Product Check’s release gate when you have recorded one (reported as recorded, and flagged if it is for an older commit), and what to do first, built only from verified facts.
  • It adds nothing of its own.

    No extra rules, scores or verdicts: every finding comes from the tool that produced it. Report-only by default, so findings never fail the build; --fail-on-error fails when a step errors.

  • It degrades gracefully.

    No specs? Spec Check is skipped. No architecture model? You get the derived as-built model to review. No PR export? Outcome Check is skipped. The other steps always run.

  • It runs where your team works.

    From a laptop, or as a GitHub Action on every pull request with the summary in the job summary. It pins tested versions of all six tools, so the chain always runs on a known-good combination.

.github/workflows/commons.yml

on: pull_request
permissions:
  contents: read
jobs:
  commons:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha>
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: enwithai/commons-check@<release-sha>
        with:
          stage: PRE_LAUNCH
          base: origin/${{ github.base_ref }}

One check, or the complete package.

Most teams do both: Commons Check for the baseline and the executive view, and individual checks as quality gates where a team is ready to enforce one.

CompareIndependent toolsCommons Check
Best forA specific question owned by a specific teamA whole-of-product view for leaders and launch decisions
Typical ownerProduct owner, reviewer, architect, platform team, engineering managerHead of engineering, CTO, delivery or quality lead
StrengthDeepest control: own config, policy and exit codes; SARIF into code scanningOne command, one summary, every report connected
In CICan gate: check exits non-zero when policy failsReport-only by default, for visibility before enforcement
Adopt byAdding the one check that removes your biggest blind spotRunning it once for a baseline, then on every pull request

Matched to your lifecycle.

Choose the stage honestly: it decides which Product Check controls apply, and a later tier always includes every earlier tier’s controls.

  1. CT-T0

    Discovery and build

    Spec Check, Impact Check

  2. CT-T1

    Alpha

    Spec, Impact and Product Check

  3. CT-T2

    Beta to pre-launch

    All five, through Commons Check on every PR

  4. CT-T3

    Launch gate

    Product Check verdict, with architecture drift now counting

  5. CT-T4

    Just launched

    Product Check with SLOs, alert rules and service graph

  6. CT-T5 and T6

    At scale

    Outcome trends, Product retest, Architecture drift

Part of the EnWithAI ecosystem. Complete on its own.

EnWithAI brings together frameworks, platforms and public tools. Engineering Commons is the public tools layer: free, open, and useful from the first command.

EnWithAIAccountable intelligence

Products · what customers run

  • CrewPE

    The AI-native SDLC platform for accepted outcomes.

  • EnSure

    Decision intelligence for accountable outcomes.

    EnterpriseBusiness

  • EnSight

    Vision intelligence agents for the cameras you have.

Commons · what we share

  • Engineering Commons

    Public tools by EnWithAI

    Spec, Impact, Architecture, Outcome, Product and Blueprint Check, plus Commons Check.

    You are here

  • Agent-Native Engineering

    Independent publication

    Patterns, practices and tools for agentic builders.

  • Decision Commons

    Shared workflows by EnWithAI

    Bid/No-Bid, Build vs Buy, Estimate and Expansion Check.

Frameworks · how we work

  • CLEAR

    A framework by EnWithAI

    Human-AI collaboration for higher performance.

  • TRACE

    Community framework

    Trustworthy, repeatable, agentic, collaborative engineering.

Models draft. Code decides. People approve.

Our commitment: the Commons stands on its own. Using a Commons tool never requires CrewPE, an account or a contract. CrewPE’s value comes from governance, orchestration and lifecycle accountability, not from holding open tools back.

Every relationship, stated precisely. Product Check’s assessment model was inspired by the CLEAR CT method. The Commons shares TRACE’s evidence-first intent; formal alignment will be assessed once TRACE is published. No certification or compliance claims.

Start in five minutes.

Requires Node.js 22, 24 or 26+, and git. Run it from the root of the repository you want assessed.

  1. 1

    Get a baseline.

    Run it once from the root of your repository.

    npx @enwithai/commons-check
  2. 2

    Add delivery data.

    Outcome Check reads pull-request and CI-run exports you create with the GitHub CLI. For full history with commits, see Outcome Check’s exporting guide.

    gh run list --limit 1000 --json databaseId,headSha,event,status,conclusion,attempt,createdAt,workflowName > runs.json
  3. 3

    Run for your real stage.

    Then read commons-report/SUMMARY.md, starting with what to do first.

    npx @enwithai/commons-check --stage PRE_LAUNCH --prs prs.jsonl --runs runs.json
  4. 4

    Put it on every pull request.

    Add the GitHub Action above, then promote the checks you trust into gates.

The tools are free. The judgment is where we help.

Organizations often want, alongside the tools, the judgment to interpret the evidence, the roadmap to act on it, and the operating model to keep it working.

  • Engineering Evidence Baseline

    For CTOs and heads of engineering who need an objective starting point

    We run the full Commons across your priority repositories, triage every finding with your teams, separate facts from hypotheses, and deliver a board-ready readout of where you stand and what to do first.

  • Launch Readiness Review

    For product and engineering leaders facing a go or no-go

    A Product Check assessment at your declared stage, mapped to your own tests and risk acceptances, with work packets your teams and coding agents can execute. Then we run the retest to prove the fixes.

  • AI Delivery Outcome Review

    For leaders asked to show the return on AI-assisted engineering

    An Outcome Check study on your own PR and CI history, AI-assisted against non-assisted and against a baseline, with sample sizes visible and a candid narrative that never ranks people.

  • Commons in the Pipeline

    For platform and developer-experience teams

    We embed Commons Check and the individual checks in your CI, tune policies and stages, connect SARIF to code scanning, and set the path from report-only visibility to enforced gates.

Ready for a governed lifecycle? When evidence needs to flow into intent, approvals, traceability and accepted outcomes across the enterprise, CrewPE takes the same discipline further.

See CrewPE

Questions teams ask.

Something we have not covered? Talk to us

Is Engineering Commons really free?

Yes. Every tool is MIT licensed, published on npm and GitHub, and works offline without an account, token or subscription. There is no paid tier of any check.

Do I need CrewPE to use it?

No. Every Commons tool is independently usable. CrewPE is a separate enterprise platform for organizations that want a governed, end-to-end engineering lifecycle.

Does it send my code anywhere, or use an AI model?

No. The tools read your repository as data, never execute it, make no network calls and call no AI model. Product Check contacts a deployed application only when you pass its URL and explicitly authorize passive requests.

Which languages and formats are supported?

Impact Check analyzes JavaScript and TypeScript, with OpenAPI and AsyncAPI contract diffs. Architecture Check reads C4 (Structurizr DSL) and FINOS CALM, plus compose, Docker and Kubernetes files. Spec Check reads any Markdown, with first-class Spec Kit support. Outcome Check reads GitHub CLI exports. Product Check reads any repository and accepts JUnit, Jest and Vitest results, npm audit, HAR files, OpenSLO, alert rules and OTel service graphs.

Will it slow down or block our pipeline?

Commons Check is report-only by default. Individual checks offer a check mode that exits non-zero when a policy you configure fails, so you choose when evidence becomes a gate.

How mature is it?

All seven packages are early releases (before 1.0), released together under one version, with versioned report schemas, tested on Node.js 22, 24 and 26, and verified by reproducible, byte-for-byte demos. We run Commons Check on our own repositories.

How does it relate to CLEAR and TRACE?

Product Check’s assessment model was inspired by the CLEAR CT method. The Commons shares TRACE’s evidence-first intent; formal alignment will be assessed when the TRACE specification is published. We make no certification or compliance claims.

Engineering Commons is an EnWithAI Technologies initiative. The tools are MIT licensed; the license does not grant use of the EnWithAI product names. CLEAR is a NetworkGain Consulting framework. Other names belong to their owners. No affiliation with or endorsement by any platform or framework vendor named on this page is implied.

Make every change provable.

Five questions. Five checks. One command. Evidence your engineers, your agents and your board can trust.

npx @enwithai/commons-check
Talk to us

GitHub: github.com/enwithai · npm: @enwithai