Baselines & Compliance

Capture, compare, and audit point-in-time snapshots of your project state.

What Are Baselines?

A baseline is a point-in-time snapshot of your entire project. When you create a baseline, AIRGen captures the current version of every entity in your project graph:

Baselines are immutable. Once created, a baseline cannot be modified or deleted. This immutability is by design — it ensures that the snapshot you present during an audit is exactly what existed at the time of capture, with no possibility of retroactive changes.

Common uses for baselines include release milestones, review gates, regulatory submissions, and change impact analysis between development phases.

Baselines vs. version history. Individual entities (requirements, documents) maintain their own version history as you edit them. A baseline is different: it captures the entire project as a coordinated snapshot. Think of it as a "group photo" of every entity at a specific moment.

Creating a Baseline

To create a new baseline:

  1. Navigate to the Baselines page from the left-hand sidebar.
  2. Click Create Baseline.
  3. Enter a label that identifies this snapshot — for example, "v1.0 Release", "CDR Snapshot", "SRR Submission", or "Sprint 14 Freeze".
  4. Enter your name as author. This records who created the baseline for audit purposes.
  5. Click Save. AIRGen captures the current version of every entity in your project.

The baseline creation process runs in the background. For small to medium projects (up to a few hundred requirements), it completes in a few seconds. Larger projects may take slightly longer. You will see a confirmation when the baseline is ready.

Name baselines consistently. Adopt a naming convention early. A pattern like "v1.0-SRR", "v1.0-CDR", "v1.0-Release" makes it easy to locate specific snapshots later. Include the version number and the review gate or milestone name.

Viewing Baseline Details

The Baselines page displays all baselines in a table, ordered by creation date (newest first). Each row shows the baseline label, author, creation timestamp, and entity counts.

Click any baseline row to expand its details. The expanded view shows a summary of all captured entities, organized by category:

Click on any category to drill down and view the specific entity versions that were captured. Each entity displays the exact content it had at the moment the baseline was created, regardless of any changes made since then.

Comparing Baselines

Baseline comparison is one of AIRGen's most powerful features for change management. To compare two baselines:

  1. On the Baselines page, select two baselines using the checkboxes in the table.
  2. Click Compare.
  3. AIRGen generates a detailed diff showing all changes between the two snapshots.

The comparison report is organized into three categories:

Change impact analysis. Use baseline comparison before a release to understand the full scope of changes since the last review gate. Compare the current baseline against the previous release baseline to generate a comprehensive change report for your review board or auditor.

Baseline comparison works across any two baselines in your project, regardless of how far apart they are in time. You can compare the first baseline with the most recent one to see the complete evolution of your project.

Compliance Evidence

Baselines provide the evidence trail required by safety and quality standards in regulated industries. AIRGen baselines directly support compliance with:

When an auditor requests evidence of your project state at a particular milestone, you provide the corresponding baseline. Because baselines are immutable and timestamped, they serve as tamper-proof records of your project's configuration at any point in time.

Audit workflow. For a typical audit, create baselines at each major review gate (SRR, PDR, CDR, release). When the auditor asks "What were the requirements at CDR?", open the CDR baseline and show the exact content. Use baseline comparison to demonstrate change control between gates.

Baselines also capture trace link coverage at the moment of creation. This means you can demonstrate that all requirements were traced to test cases, architecture blocks, or design documents at the time of the review — even if trace links have been modified since then.