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

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.

​

Inline requirement quality

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.

​

Verification method

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.

​

Duplicate / contradiction detection

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.

​

Standards-clause linkage

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.

​

Chat with the requirements document

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.

​

Test suggestions for uncovered requirements

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.

​

Gap explanation

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>, 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