Evidence-Gated Assurance Framework (EGAF) overview

2026-08-30 · Assurance

Teams that ask "what does your compliance framework actually do" are asking a delivery question: can this organization prove, at a given commit, that the checks it claims were run, by independent tools, with evidence a stranger can re-read. The Evidence-Gated Assurance Framework (EGAF) is Koinessa's answer to that question. It is an assurance framework. A project claims conformance to EGAF L1, L2, or L3 at a given commit, with evidence attached. It is not a certification, an accreditation, or an authorization to operate.

This page is the overview — the URL to send a buyer, a CISO, or a reviewer. The ten industry-profile articles go deeper. The rest of the engineering blog is the surrounding Evidence-Gated Agentic Development practice EGAF sits on.

Pre-release, founder-operated system; current capability labels describe the evidence boundary.

What the Evidence-Gated Assurance Framework does

EGAF is in flight. It is a spec-first, data-driven bar for verified software delivery, compiled from the regimes engineering organizations already get asked about and from the ways of working this system already runs: traceability from a requirement to a test, low complexity, low duplication, coverage of changed code, mutation testing, signed evidence, and supply-chain hygiene.

Three parts, every run:

  1. A control catalog. Each control is a machine check (an artifact an independent tool produced) or an evidence: attestation (a signed statement by a named principal). A named check with no backing artifact is DRIFT, never PROVEN. An empty file is not a verdict. The catalog this site describes is a measured snapshot: 109 controls, vendored into Koinessa at pin 0.0.0-dev+98d08ef on 2026-08-30.
  2. A deterministic evaluator. Same inputs produce a byte-identical conformance report. The evaluator does not run tests or scanners. It reads artifacts other tools already produced and records their digests. An agent cannot manufacture PROVEN without producing the artifact the check names.
  3. A committed profile. .egaf/profile.yaml in the consumer repo is what CI evaluates. If that file is absent, the evaluator uses the bundled Core profile, so L1 mandatory controls always apply. Profiles may only tighten a threshold.

That is the whole product claim. Frameworks are guidance. Controls are behavior. Evidence proves the behavior occurred. Organizational burdens — training, physical security, BAAs, a C3PAO assessment, DO-330 tool qualification, a third-party Type II engagement — stay with the organization. The Koinessa whitepaper is the longer argument; the verified-delivery report is what this system already publishes about itself.

How a run is scored

Three levels. L1 Core is mandatory to claim any EGAF conformance. Fail one applicable L1 control and the report's first line is L0. An EXCEPTION never satisfies an L1 control. L2 Regulated adds industry-profile controls. L3 Safety-critical adds independence, structural coverage, tool-qualification inputs, and hazard linkage.

Control status collapses the seven check outcomes already used in Koinessa evidence bundles:

Check outcome Control status
PASS PROVEN
FAIL FAILED
SKIPPED-NOT-APPLICABLE with a recorded reason NOT-APPLICABLE
INFRASTRUCTURE-ERROR, TOOL-MISSING, EVIDENCE-INVALID, or ABSTAIN DRIFT
Missing evidence DRIFT

The report always shows two honesty lists at the same visual weight: Not proven (FAILED and DRIFT) and Accepted without proof (NOT-APPLICABLE and EXCEPTION). A clean badge over an empty honesty block is the failure the framework exists to prevent. The public specification repository is planned; until its GitLab group exists, treat EGAF as a labeled pre-1.0 draft with publication pending. Koinessa's own first mainline conformance report is planned.

This is the same discipline as Evidence-Gated Agentic Development: the model generates the work, the pipeline proves it, the brain architecture remembers it. EGAF names the bar the pipeline is proving against.

The ten industry profiles

Every profile except Core extends Core and unions more frameworks. None of them loosen a threshold. Pick the article for the regime you actually ship under. These ten pages are the body of the series; this overview is the index.

L1 — the baseline

L2 — regulated overlays

L3 — safety-critical overlays

Who this is for: platform, DevEx, and DevSecOps teams at engineering organizations that already run multiple AI coding agents, already have CI, and have a visible verification or policy problem. The Koinessa home page states the product position. The developer is a user of the pipeline; the economic buyer is the team that has to answer a questionnaire without inventing a certificate.

What this overview does not claim

EGAF conformance is a per-commit statement a project makes about itself with evidence attached. Citing a framework in a profile is a crosswalk, not a state the adopter has reached. No whole-task performance multiplier. No customer names. Planned items carry no dates. The limitations status report is the honest sibling of this page: what the delivery system does not do yet.

If you arrived here from a vendor questionnaire, start with Core, then open the one L2 or L3 profile that matches the regime on the form. If you arrived here from the white paper series, continue through the verification gap and why generated code fails silently — EGAF is the named bar on the far side of that gap.

The rest of the engineering blog

Every other article currently on koinessa.com, grouped so this page can be the one link you send.

The thesis and the gap

How Koinessa runs

Status, limits, next

The blog index is the chronological listing. This overview is the map.