Baseline requirements and review change impact

The Requirements surface keeps ReqIF parsing and structural analysis in the resident host. Use it to inspect hierarchy and traceability, record verification against same-model evidence artifacts, name an immutable requirements state, and compare two exact states.

This guide is verified against the frozen Grid 0.65.0 candidate source at commit 710c7e841b036d26ded22e133b5bcc4023503636, including the current formal signoff workflow. The companion film remains a separate Grid 0.63.2 release capture and carries its own older evidence receipt.

Prepare a valid ReqIF input

The import control accepts .reqif and .reqifz. Before importing, check the actual interchange artifact rather than relying on its extension alone:

Check	Grid 0.65.0 candidate contract
Version	ReqIF 1.2 or 1.2.1 is supported, along with compatible 1.0 headers.
Plain document	A .reqif file contains the XML document directly.
Archive	A .reqifz archive contains exactly one member whose name ends in .reqif, case-insensitively.
Archive safety	Unsafe paths, symlinks, special files, duplicate or case-colliding names, and zero or multiple ReqIF members are rejected.
Browser transfer	The selected file must not exceed 64 MiB. The host also applies independent archive, XML, structure, and collection limits.

The Rust host owns ZIP extraction, XML inspection, sanitization, validation, normalization, and canonical export. The browser does not repair unsupported XML. A successful import creates immutable source and normalized-bundle artifacts and makes the returned bundle the current Requirements head.

Create a Requirements surface from the workbook menu. For a source-defined fixture, its configuration can be kept explicit:

version = 1
kind = "requirements"
title = "System requirements"

[layout]
density = "comfortable"
default_view = "requirements"
show_summary = true

1. Import and inspect

1. Open the Requirements surface in authoring mode.
2. Choose one valid .reqif or single-document .reqifz file, then select Import ReqIF.
3. Confirm the artifact banner shows the document title or logical name, ReqIF version, header identifier, and source digest.
4. Check the coverage summary: Requirements, Traced, Untraced, Orphaned, Passed, Failed, Blocked, Not run, and Conflicts.
5. Use Requirements to inspect hierarchy and typed attributes, and Traceability to inspect authored source-to-target relations.

The Requirements and relation views are bounded. Pagination and explicit returned, total, or truncation evidence are part of the result; a page is not a claim that the entire document fit in one browser response.

2. Record verification with evidence links

Select a requirement, then complete Record verification:

1. Choose Passed, Failed, Blocked, or Not run.
2. Enter the verification method and observed time.
3. Add zero or more evidence artifact IDs, one per line or comma-separated. Every ID must name a valid artifact in the same model.
4. Add notes when the observation needs context, then select Record verification.

The host publishes an immutable verification event and an immutable successor Requirements head. The surface adopts the returned successor head for later verification, export, baseline, and comparison work. A stale writer fails instead of overwriting a concurrent receipt; an older head remains readable but cannot accept another verification append.

Use the Verification view to confirm the requirement ID, status, conflict indicator, and evidence artifact IDs. The link records which resident artifacts support the observation. It does not decide whether the evidence is persuasive and does not constitute approval or signoff.

3. Publish a named baseline

In Baselines & change impact:

1. Enter a concise baseline name. Grid whitespace-normalizes it and limits the canonical name to 128 UTF-8 bytes.
2. Confirm that Target artifact is the current committed Requirements head.
3. Select Publish baseline.
4. Retain the returned baseline artifact ID with the name and target state shown by the surface.

The baseline is immutable and its canonical name is a permanent binding. Retrying the same name against the same target is idempotent; attempting to bind that name to a different state fails.

4. Compare two exact states

Prepare a second committed Requirements state by importing another valid document or by advancing the current head with verification receipts. Then:

1. Set Before artifact ID to a committed Requirements state or named baseline.
2. Set After artifact ID to another committed state or named baseline.
3. Select Publish change impact.
4. Read the returned report artifact ID, exact before/after state IDs, changed requirement and relation sections, directly suspect relations, and authored-direction upstream and downstream impact.
5. Check every matched and truncated indicator before treating a displayed list as complete.

The host publishes a pinned, immutable report. The surface stores and renders its artifact reference; it does not recompute impact in the browser.

The Grid 0.65.0 candidate caps each returned ID section at 2,000 entries and each upstream or downstream traversal at 100,000 edges. A requirement is also reported as modified when its immutable verification history differs between the two states. Directly suspect relations include relations that changed and relations touching a changed requirement; a relation-only change seeds downstream traversal from its authored source and upstream traversal from its authored target.

Read the visible evidence

Evidence	What it establishes
Inspection banner	The imported title or logical name, ReqIF version, header identifier, and a prefix of the source SHA-256 digest.
Coverage summary	Bounded hierarchy, trace, verification-status, and verification-conflict counts for the current committed state.
Requirement detail	Stable identifier, type, hierarchy paths, typed attributes, authored trace links, verification state, and evidence artifact IDs.
Baseline reference	The immutable baseline artifact ID, canonical name, and exact target state.
Impact identity	The immutable report ID plus the exact before and after artifact identities used by the host.
Structural diff	Sorted added, removed, and modified requirement and relation IDs. A verification-history difference also marks its requirement as modified.
Propagation	Directly suspect relation IDs and upstream/downstream reachability following authored relation direction, including relation-only change seeds.
Bounds	Matched, returned, and truncation evidence for ID sections capped at 2,000 entries and traversal capped at 100,000 edges per direction.

Canonical export returns plain ReqIF XML from the reached base document. Grid verification receipts are not inserted as unsupported ReqIF extensions.

Boundaries in the Grid 0.65.0 candidate

• Change impact compares stored requirement and relation structures plus immutable verification histories, then reports graph reachability. It does not infer requirement meaning or SysML semantics.
• A directly suspect relation either changed itself or touches a changed requirement. “Suspect” is a review signal, not a defect claim.
• A verification receipt records a status, method, observation claim, optional notes, and links to same-model evidence. It is not approval or signoff.
• A named baseline identifies an immutable state. Publishing one does not promote or release that state.
• A change-impact report does not approve, sign off, promote, or release either input.
• The Requirements surface does not provide SysML authoring or controls to start or approve a governed signoff workflow, and it does not promote or release a state.
• The Grid 0.65.0 candidate includes a verified requirements-signoff Domain Pack definition for deployments that install and admit it. That separate human-governed workflow requires one exact named baseline and one exact host-published change-impact report, requires the baseline target to equal the report's after-state, reopens same-model lineage, recomputes the report with default limits, refuses truncation or substituted evidence, and enforces trusted roles, a reason, a signature, and separation of duties. Workflow completion is the signoff record; it creates neither a second signoff artifact nor a release.
• The companion film's Design review baseline is the report's before-state, while the revision is its after-state. That pair demonstrates review impact but is not a formal signoff pair. A signoff attempt must first name the reviewed after-state as its own baseline and then submit that baseline with the exact impact report through the separately admitted workflow.
• Host and UI limits are deliberate. Review truncation fields rather than assuming a bounded list is exhaustive.
• Imported source, normalized bundle, verification event, successor head, baseline, and impact report are immutable artifacts. Follow their exact IDs when reconstructing a review.

Deterministic film capture

Change one requirement; see the blast radius follows this recipe with the real Grid app. Its verified release receipt binds the Grid 0.63.2 source commit, reviewed storyboard and capture assertions, local ReqIF fixtures, ElevenLabs narration, and final media; no response stub supplies the impact result.

Prepare two small, valid ReqIF 1.2 fixtures with stable identifiers and no external resources:

• baseline.reqif: requirements REQ-PEDAL, REQ-BRAKE, and REQ-STOP; relation REL-PEDAL-BRAKE from pedal to brake; and relation REL-BRAKE-STOP from brake to stop. The braking requirement says the vehicle stops within 42 metres.
• revision.reqif: the same header, types, hierarchy, requirement IDs, relation IDs, and relation endpoints. Its only authored change is the REQ-BRAKE attribute, from 42 metres to 35 metres.

This short film deliberately omits verification so the import, named baseline, and structural impact remain readable. Verification evidence remains a separate supported workflow described earlier in this guide.

1. Start from a fresh disposable model, fixed viewport, and source-defined Requirements surface. Import baseline.reqif and assert ReqIF 1.2, header BRAKE-HEADER, three requirements, and two relations in the host receipt.
2. Select REQ-BRAKE. Capture the 42-metre typed attribute and its two trace links.
3. Publish the baseline name Design review. Capture its immutable baseline artifact ID and exact target state.
4. Import revision.reqif, select REQ-BRAKE again, and capture the 35-metre typed attribute. Assert that the source and bundle artifact IDs changed while all requirement and relation identifiers stayed fixed.
5. Use the named baseline artifact as Before and the revision bundle as After, then publish change impact.
6. Capture the exact complete result: one modified requirement (REQ-BRAKE); zero added, removed, or modified relations; both adjacent relations directly suspect (REL-BRAKE-STOP, REL-PEDAL-BRAKE); REQ-PEDAL upstream; and REQ-STOP downstream.
7. Reopen /artifacts/:reportArtifactId/content and assert that the retained JSON deep-equals the publication receipt. Keep the ReqIF bytes, file names, baseline name, Grid version, and viewport fixed. Do not use a wall-clock input, external connector, generated fixture identifier, response interception, or hover-only evidence.
8. If any section or traversal reports truncation, stop; this three-node fixture should remain completely visible.

The capture passes when viewers can follow exact artifact identities from both imports through the named baseline and retained impact report, and the narration explicitly stops at structural review evidence rather than claiming SysML semantics, approval, signoff, promotion, or release.