---
title: "Introduction"
description: "Defining and Iterating on Done"
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.testandaccept.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

Test And Accept is platform developed to help you and your team get to finished. 

As developers and team engineers, we understood that requirements are the most important thing to getting anything done. But requirements were hard. 
What this platform does is remove the friction from creating requirements.


Developed as a scaffolding for a project by a developer, the platform was inspired by the system that we used to deliver 
high consequence, mission critical systems to the US Military, and our experience working in software development in large enterprises. 


## Purpose & Philosophy

This platform provides a single, auditable flow from articulated work (the Statement of Work) to objective acceptance (a run‑once checklist), without the heavy, meeting‑driven rituals that often stall requirements. Work is decomposed into verifiable parts, change is handled asynchronously, and results are traceable end‑to‑end.

### Key ideas:

#### Single source of truth 
Every test traces back to an approved criterion, which traces back to a task item, which traces back to a Statement of Work (SOW), inside a Project for a Client.

#### Asynchronous by default 
Owners propose and apply small changes directly; larger shifts move through a lightweight Request for Comment (RFC).

#### Evidence‑based acceptance 
Acceptance procedures are auto‑composed from the tests under each criterion and executed as a checklist—clear steps, pass/fail outcomes, artifacts, and signatures.

#### Continuous improvement
Failures route into Root Cause Analysis (RCA) to document corrective and preventive actions.

- **Start your first project**
- **Learn the core concepts**
- **Check out the API**
- **Connect your AI assistant (MCP)**

## Core Objects and Relationships

Client
  └── Project
        └── Statement of Work (SOW)
              └── Task Item
                    └── Criterion
                          └── Test Item


### Clients
Organizations you deliver to.

### Projects
Engagements for a Client; the container for SOWs, runs, RCAs, and artifacts.

### Statements of Work (SOWs) 
Contracted scope, milestones, and deliverables. The SOW defines what must be true at acceptance.

### Task Items 
Units of delivery within the SOW (features, systems, work packages).

### Criteria (Acceptance Criteria) 
Objective conditions that define “done” for a task item.

### Test Items
Verifications attached to a criterion (steps, expected results, evidence).

### Requests for Comment (RFCs) 
Structured proposals for non‑trivial changes to SOWs, task items, criteria, or tests.

### Root Cause Analysis (RCA) 
Post‑failure analysis linking failed runs to causes and corrective/preventive actions.

### Traceability:
A built‑in matrix allows navigation from SOW → Task Item → Criterion → Test Item → Test Run Result (and back). This is the audit backbone for acceptance.

Source: https://docs.testandaccept.com/index.mdx