In this guide, as-designed means the approved product definition; as-built means the actual realised unit; and as-tested means the precise product, software, setup and environment represented by a test result. The first two terms are used in NASA acceptance-data guidance and ECSS configuration-management material. “As-tested” is a practical evidence-applicability label here, not a universal formal baseline. A trustworthy programme reconciles the three states so that approved intent, physical reality and verification evidence refer to the same configuration.
What do as-designed, as-built and as-tested mean?
| State | Working definition | Representative records | Control question |
|---|---|---|---|
| As-designed | The approved product definition intended to be realised for the applicable baseline | Requirements, interface definitions, released drawings or models, software baseline and approved processes | What was authorised for this configuration? |
| As-built | The actual unit or product configuration after manufacture, assembly, software loading and incorporated changes | Build records, installed-item identities, software load, inspections, rework, nonconformances, deviations and waivers | What is actually present in this identified article? |
| As-tested | The specific product, setup and conditions to which an evidence result applies | Test-article identity, hardware and software configuration, procedure, equipment, calibration context, environment, sequence and anomalies | What exactly did this evidence assess? |
NASA’s configuration-management guidance describes baselines as agreed product descriptions at a point in time and makes configuration verification and status accounting part of the control process. ECSS-M-ST-40C Rev.1 requires systematic comparison of a configuration item’s as-built configuration with its as-designed configuration.
Why must the three states be reconciled?
Evidence is only meaningful for the configuration it represents. NASA’s product-verification guidance identifies the product, approved requirements, verification plans and procedures among the process inputs. If a flight unit differs from the released design, a test may prove the performance of the departure rather than the approved product. If hardware changes after a test, the original result may remain valid, become partly applicable or require repetition; that is an engineering disposition, not a conclusion software should guess.
NASA’s acceptance-data recommendations include complete test history, test environments and sequence, as-built versus as-designed records with reconciliation of deltas, installed-part traceability, anomalies, waivers and deviations. The source is NASA guidance for particular assurance and acceptance contexts, not a universal deliverable list for every project.
A practical reconciliation asks:
- Which released design baseline and effectivity apply to this identified unit?
- Which parts, software, settings, rework and approved departures are actually present?
- Which configuration and environment did each verification activity assess?
- Did a later change touch the requirement, interface, function or failure mode supported by that evidence?
- Who has authority to accept equivalence, require supplementary analysis or order a retest?
How should deviations, waivers and nonconformances be represented?
The ECSS glossary defines nonconformance as non-fulfilment of a requirement, while ECSS-Q-ST-10-09C Rev.1 addresses control of deliverable products that fail to conform to project requirements. NASA’s configuration-management guidance describes a waiver as authorised release from a requirement and notes that an authorised waiver does not itself change the baseline.
Keep four facts separate: the observed condition, the applicable requirement or design definition, the authorised disposition, and whether a baseline change follows. A repaired or use-as-is unit can remain different from the nominal design while still being authorised for a bounded use. That departure must stay attached to the unit and to evidence whose validity depends on it.
Because authorities use deviation and waiver terminology differently, do not infer timing or approval rights from the word alone. Use the programme’s approved definitions, identify the affected item and limit, and preserve the customer or control-board disposition.
Which system should own each configuration record?
The matrix below is an architectural recommendation, not a standards mandate. Name the authoritative system for each record type in the programme’s configuration-management plan, and synchronise references without allowing two systems to claim the same released truth.
| Record domain | Typical authority | Arc’s appropriate role |
|---|---|---|
| Requirements, interfaces, decisions and programme baselines | Requirements or systems-engineering authority defined by the programme | Connected programme records, applicability and baselines, traceability and controlled change |
| CAD, drawings, product definition and BOM | CAD/PDM/PLM environment selected by the organisation | Reference controlled identifiers and mapped relationships where the deployment supports them; retain native authoring and release authority |
| Build execution and serial genealogy | Manufacturing and production systems selected by the organisation | Relate supplied configuration applicability; Arc’s public capability reference does not document execution or genealogy ownership |
| Nonconformance and quality disposition | Approved QMS and material-review authority | Connect risks, anomalies and dispositions with affected evidence where configured; retain formal quality authority |
| Test execution, raw data and calibrated equipment | Test system, laboratory and verification authority | Connect plans, cases, executions, results and evidence references to requirements and applicable configurations |
What does configuration reconciliation look like for a flight unit?
The released power-distribution design for Meridian-2 Baseline D specifies connector bracket BRK-14. During Flight Unit 2 assembly, an inspection finds that the approved bracket cannot achieve the required harness clearance on that unit. The quality authority records the nonconformance and approves a bounded rework using bracket BRK-14R while the design authority evaluates a permanent change.
The as-designed state remains Baseline D until the permanent change is approved and released. Flight Unit 2’s as-built record includes BRK-14R, the nonconformance, rework instruction and disposition. A vibration test then runs on that identified unit with its actual software load and instrumented bracket; the result is as-tested evidence for that configuration.
When Baseline E later adopts BRK-14R for future units, the team does not merely mark every earlier test “current”. It assesses whether Flight Unit 2’s evidence supports the released design, whether qualification assumptions are equivalent and whether other units require inspection or additional evidence. The decision and rationale are recorded against each applicable configuration.
How should a change affect existing verification evidence?
- Identify the delta: compare the proposed or released change with the baseline represented by the evidence.
- Traverse affected relationships: inspect requirements, interfaces, functions, hazards, procedures, models and test cases.
- Check configuration facts: confirm unit, variant, hardware, software, environment and effectivity rather than relying on a shared product name.
- Disposition each result: retain, retain with justification, supplement by analysis or inspection, or repeat the activity.
- Approve and preserve: record the competent authority, rationale, limitations and new evidence status without deleting the historical result.
This workflow is Arc’s recommendation, informed by the configured-product and process-input controls in NASA’s product-verification guidance. The applicable verification plan and change authority determine which activities must actually be repeated.
Where can Arc connect configuration and evidence?
Arc’s connected programme model can relate requirements, interfaces, risks, verification and evidence. Its variants and configuration capability represents applicability and configuration baselines, while verification and test management connects executions, results and evidence to the requirements and configurations they support.
Arc’s public capability reference does not document CAD authoring, drawing release, BOM ownership, manufacturing execution, serial genealogy, calibrated laboratory control or QMS authority. Those systems and accountable functions remain authoritative as defined by the customer. Arc should connect their controlled references to programme decisions and evidence, not duplicate or silently overrule them.
What should you read next?
Control a configuration delta with the ECR, ECO and ECN guide, distinguish the two evidence questions with verification vs validation for space systems, expose requirement-to-evidence relationships with the requirements traceability matrix guide, and manage evidence freshness with continuous verification for agile hardware.
What are the frequently asked questions?
What is the difference between as-designed and as-built?
As-designed describes the approved product definition intended for implementation. As-built describes the actual realised unit, including incorporated changes and authorised departures. Configuration reconciliation determines whether the unit matches the approved definition or has accounted-for deltas.
What does as-tested mean?
In this guide, as-tested means the exact hardware, software, setup, environment and procedure configuration represented by a test result. It is a practical evidence-applicability label, not a universal formal baseline term.
Does an approved waiver change the design baseline?
Not by itself under NASA’s published configuration-management description. A waiver authorises departure from a requirement without changing the baseline. Apply the definitions and authority rules in the governing programme.
Can evidence from one flight unit verify another?
Only when the programme’s approved verification strategy permits it and the relevant design, build, software, environment and acceptance assumptions remain applicable. The reuse decision and its rationale should be explicit.
Is Arc a PLM, MES or QMS system of record?
Use the authority matrix and cited capability evidence in this article when assigning roles. The customer’s configuration-management plan should name the authoritative system for product definition, manufacturing, quality and test records and keep those authorities distinct from Arc’s connected programme role.