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

# AI for Requirements & Traceability

> Inline AI assists across the requirement authoring lifecycle - INCOSE quality, verification-method suggestions, duplicate detection, standards-clause linkage, gap explanations, test suggestions, and chat-with-document.

# AI for requirements & traceability

Roboticks layers eight typed AI assists across the requirement-authoring lifecycle. Each one is a card on the requirement detail page or the traceability matrix — never an opaque batch job. The engineer keeps the keyboard; the AI just removes the staring-at-a-blank-page tax.

<h2 id="quality">
  Inline requirement quality
</h2>

Surface: **Requirement detail → Quality card.** Fires automatically on first open of any requirement; refreshes when the requirement text changes.

Returns an INCOSE-style structured assessment:

* **Ambiguity:** flagged phrases ("as appropriate", "fast enough", undefined pronouns).
* **Atomicity:** is this one requirement or three?
* **Testability:** can a `@confirms` test pass-fail this requirement, or is the acceptance criterion vague?
* **Verifiability:** could this be checked by analysis / inspection / demonstration if not by test?

Each finding carries a short rationale and a suggested rewrite. Click "Apply" on a rewrite to draft a snapshot revision the team can review.

Task type: `REQUIREMENT_QUALITY` — Haiku-tier, 2 token-cost. The cheap-and-fast path means it runs on every open without burning the org's grant.

<h2 id="verification-method">
  Verification method
</h2>

Surface: **Requirement detail → Verification card.**

Suggests the most appropriate verification method (Test, Analysis, Inspection, Demonstration) plus a one-paragraph rationale and a bulleted test-design sketch. The engineer turns the sketch into actual `@confirms` test code; the SDK plugin then closes the loop in the matrix.

Task type: `REQUIREMENT_VERIFICATION_METHOD` — Haiku.

<h2 id="duplicate-check">
  Duplicate / contradiction detection
</h2>

Surface: **Requirement detail → Duplicates card** (visible when the project has > 5 requirements).

Embeds up to \~50 peer requirements from the same project into the prompt and asks Sonnet to find:

* **Near-duplicates** — same intent, different wording. Suggested merge.
* **Direct contradictions** — REQ-014 says "the AMR shall stop within 200 ms", REQ-219 says "within 50 ms"; surfaced for resolution.
* **Overlap** — the requirement is partly covered by another; suggested narrow-scope rewrite.

Each finding includes the conflicting requirement ID + similarity confidence. The card surfaces only findings above a confidence threshold (currently 0.7) so the engineer isn't drowned in noise.

Task type: `REQUIREMENT_DUPLICATE_CHECK` — Sonnet, 20k input budget, 10 token-cost.

<h2 id="standards-link">
  Standards-clause linkage
</h2>

Surface: **Requirement detail → Standards card.** Visible when the project subscribes to at least one standard.

The prompt embeds up to \~80 candidate clauses (clause ID + short text) from the org's subscribed standards. Sonnet returns a ranked list of clauses the requirement most plausibly satisfies, each with a one-line rationale.

The engineer clicks **Confirm** to record an explicit `requirement_standard_mappings` row, or **Reject** to teach the model (negative signal stored on the AIAnalysis row).

Task type: `REQUIREMENT_STANDARDS_LINK` — Sonnet, 20k input budget, 10 token-cost.

<h2 id="doc-chat">
  Chat with the requirements document
</h2>

Surface: **Requirements upload page → chat dock.** Appears after a PDF / ReqIF / YAML document has been parsed.

The engineer asks free-form questions about the extracted requirements (e.g. "which requirements mention emergency stops", "are there any without acceptance criteria"). Sonnet answers grounded in the parsed requirements list, with explicit citations to requirement IDs.

The conversation persists per upload, so opening the same document next week resumes the thread. Token cost is rate-limited per session at the project layer to keep this from chewing through Free-tier grants.

Task type: `REQUIREMENT_DOC_CHAT` — Sonnet, 30k input budget, 8 token-cost per turn.

<h2 id="test-suggestion">
  Test suggestions for uncovered requirements
</h2>

Surface: **Traceability matrix → uncovered row → "AI Suggest tests"** action.

For a requirement with zero passing linked tests, Sonnet drafts 3-5 candidate test sketches grounded in the requirement text, the project's existing test conventions (it scans a sample of nearby tests), and the project's chosen ROS distro / sim engine. Each sketch is a `def test_*` skeleton with the right `@confirms` decorator filled in.

You copy the skeleton into your repo, flesh out the body, and push — when the next CI run uploads the JUnit-with-confirms XML, the matrix flips the requirement from "uncovered" to "covered".

Task type: `REQUIREMENT_TEST_SUGGESTION` — Sonnet, 8k input budget, 6 token-cost.

<h2 id="gap-explain">
  Gap explanation
</h2>

Surface: **Traceability matrix → "Why uncovered?"** chip on any uncovered row.

A short Haiku call generates plain-English context for *why* a requirement is uncovered:

* No tests link to it.
* Linked tests are failing.
* Linked tests have never executed in the current branch.
* Linked tests skip when `requires_sim` doesn't match the current pool.

For the cases the platform can resolve mechanically (e.g. tests skipped because the pool was wrong), the message includes the one-click fix.

Task type: `REQUIREMENT_GAP_EXPLAIN` — Haiku, 2 token-cost.

## Traceability AIAssist primitive

The matrix UI uses a single React component, [`<AIAssist>`](https://github.com/roboticks-io/roboticks/blob/main/frontend/src/components/ai/AIAssist.tsx), to render every uncovered-row inline suggestion. It is the standard shape: a small icon, a one-line summary, an "Open" disclosure, and a feedback widget. Every Roboticks AI surface that lives inside a row uses this primitive so the interaction feels consistent across the product.

## Requirements ingestion is its own AI surface

Uploading a PDF or ReqIF document triggers `REQUIREMENT_GENERATION` (Sonnet, max-window) on the parser Lambda. That call's cost is *much* higher than the inline assists above — typical worst-case is \~160 000 ai\_tokens — so AI requirement ingestion is implicitly Team+ even though the Free plan technically has the API endpoint enabled.

## Next

<CardGroup cols={2}>
  <Card title="Test debugging" icon="bug" href="/ai/test-debugging">
    Failed-test triage, flakiness, sim-vs-real, log anomalies.
  </Card>

  <Card title="Evidence & standards" icon="scale-balanced" href="/ai/evidence-and-standards">
    AI for the audit handoff.
  </Card>

  <Card title="Requirements docs" icon="file-lines" href="/requirements/overview">
    Authoring workflow without the AI lens.
  </Card>
</CardGroup>
