Design Artifacts

Why use design artifacts?

Your connected workbook is the operational source of truth. Design artifacts give that source of truth context.

In real programs, requirements do not live in one place. User needs may start in a URS, software requirements may be reviewed in a SwRS, hardware constraints may be defined in an HRS, and the RTM workbook may only reflect the subset that has been brought into the live traceability flow. If you only sync the workbook, you can miss the evidence that matters most during review: what the upstream document actually said, when it diverged, and whether the workbook still matches it.

Design artifacts solve that.

When you upload requirement documents and RTM snapshots into Live, RTMify parses their requirement assertions and places them into the same traceability graph as your connected workbook, tests, risks, code, BOMs, SOUP, and execution evidence. That gives you a second lens on the system: not just what the workbook says now, but what the controlled source documents also say.

Benefits

• Catch requirement drift early. Live can show when the same requirement ID carries different text across the RTM, SRS, SysRD, URS, SwRS, or HRS.
• Preserve upstream intent. Auditors and reviewers can see the original requirement wording from the source document, not just the current workbook row.
• Close traceability blind spots. Requirements that exist in a design document but never made it into the workbook are surfaced instead of disappearing quietly.
• Strengthen review readiness. Artifact-backed assertions make source provenance visible in MCP, reports, suspect review, and requirement trace views.
• Support real document-controlled workflows. Teams can keep using their existing Word specifications and workbook exports without forcing everything into one authoring system on day one.
• Reduce false confidence. A green workbook is less meaningful if the upstream controlled documents disagree with it. Artifacts make that disagreement visible.

Supported artifact types

Live recognises two categories: workbook snapshots (.xlsx) and requirements documents (.docx).

Requirement ID format

Live identifies requirement assertions by recognising structured IDs in document text. This is the only mechanism for requirement extraction: if a requirement statement in a source document does not include an ID in this format, it will not be extracted.

A structured ID must satisfy all of the following rules:

• At least 3 characters total.
• At least one hyphen.
• No leading or trailing hyphen.
• No consecutive hyphens (each hyphen must be preceded and followed by at least one character).
• Every character is alphanumeric (A–Z, a–z, 0–9) or an underscore. Spaces, slashes, dots, and parentheses are not permitted.

IDs are case-preserved but normalised (BOM stripped, smart quotes replaced, whitespace collapsed) before comparison. REQ-001 and req-001 are treated as distinct IDs.

What happens on upload

1. Live stores the file and records the artifact type, source filename, and upload timestamp.
2. The parser extracts requirement assertions, including requirement IDs, descriptions, and any declared trace references present in the file.
3. Assertions are added to the graph as DesignArtifact nodes linked to the originating artifact record.
4. Where an assertion ID matches a requirement already in the connected workbook, Live creates a cross-reference edge. Unmatched assertion IDs are retained as warnings rather than errors and become linkable when the workbook catches up.
5. The artifact and its parse status appear in the Dashboard's Artifacts section.

Parse status reference

Each extracted assertion carries a parse_status that appears in the artifact detail view. Statuses other than ok indicate that the extracted text may need attention before the assertion can be treated as reliable.

Artifacts vs. the connected workbook

Conflict resolution and authoritative source

When multiple sources assert the same requirement ID — the connected workbook, a snapshot, an SRS, a SwRS — Live resolves them into a single effective statement using a fixed priority rule and records the outcome as a text_status on the requirement.

Resolution rules

The workbook assertion always wins as the effective_statement when it is present. Artifact-only assertions are then compared against it. If no workbook assertion exists, artifact sources are compared against each other. The authoritative_source field identifies which artifact provided the winning text; it is null when multiple artifact sources conflict and there is no workbook to break the tie.

Example