Evidence

How we substantiate delivery claims.

Specifications, decisions, review findings, tests, releases, and agreed outcome measures remain connected so a claim can be traced to evidence—not just asserted.

NCAI-owned method sample

What connected evidence looks like.

This representative structure contains no client material. It shows the chain an engagement maintains from a requirement through acceptance and release.

REQ-01401 / 04

Requirement and acceptance envelope

Business outcome, constraints, owner, assumptions, and testable definition of done.

Feeds architecture and backlog

ADR-00702 / 04

Architecture decision record

Decision, alternatives, evidence, consequences, status, and accountable approver.

Constrains implementation

REV-02103 / 04

Independent review finding

A separate reviewer checks the implementation against the requirement and decision.

Feeds correction and retest

REL-00304 / 04

Acceptance and release evidence

Test result, risk disposition, release record, and traceability back to business intent.

Supports a publishable claim

Evidence class: illustrative method artifact. Representative structure—not client work, a measured result, or a performance guarantee.

Inspectable public product evidence

The operating model produces working software.

These public products can be inspected directly. Each demonstrates an aspect of the same delivery discipline; none is presented as a client outcome.

ValulyLive · Public

Evidence-grade domain valuation

Prices a domain as a market band from recorded sales, cites every comparable, and publishes its own median error.

Shows its work — delivery discipline, made public.

valuly.ai ↗

MeetCrewLive · Public

AI meeting participant

Joins Teams, Zoom, Webex, and Meet by name, answers when addressed, and hands memory back to your agent. Always disclosed; no voiceprints stored.

Microsoft-stack native, governance-first.

meetcrew.ai ↗

SpecStepLive · Public

Build-ready specifications

Turns messy product ideas into requirements, architecture, risks, and acceptance criteria your AI coding tools can build from. MCP-native.

The spec system inside our own delivery model.

specstep.com ↗

Delivery patterns

The work we are prepared to substantiate.

Client examples are published only when their artifacts, claims, provenance, and publication authority are independently supportable.

Greenfield delivery

Functional requirements through specification, design, implementation, testing, ALM, and handoff.

Project rescue

Taking over a difficult inherited solution and restoring architecture, quality, governance, and delivery confidence.

Team enablement

Structured AI-delivery routines that improve planning, context retention, review, and documentation.

Governance-platform adoption

Session state, decisions, lessons, rules, backlog tracking, and model-agnostic controls, installed.

One place this evidence discipline matters most is Dynamics 365 project rescue, where inherited assumptions must be replaced with inspectable architecture, test, risk, and release records before delivery confidence can return.

Publishing discipline

Five evidence classes. No implied proof.

We identify the status of published results instead of turning estimates, benchmarks, or permission-pending material into facts.

Verified fact

Confirmed against an inspectable first-party or authoritative source.

Client-attributed

A client's own statement, published only with written approval.

Directional

A qualitative or benchmark indication, not a measured client result.

Estimate

A scoped projection, explicitly identified and never presented as a guarantee.

Permission-pending

Material excluded from public proof until written authority exists.