Arc Skills / Requirements

Resolve TBDs and TBCs in requirements

Arc Skills inventories unresolved placeholders in a requirement baseline and distinguishes absent decisions from unconfirmed candidates. It returns a prioritized log without silently substituting draft values into controlled statements.

Use this skill

Use Arc Skills to review and resolve TBD and TBC entries in the supplied baseline.

Inputs:
- Exact placeholder occurrences with requirement IDs, wording, fields, and revisions
- Candidate values or definitions with source locators and approval status
- Decision owners, parent limits, interfaces, and dependent tests

Return a placeholder inventory and decision log with candidate evidence, owner, status, and downstream effects.
Keep controlled wording unresolved until the authorized decision is recorded; do not promote draft values

Set up the toolkit · Read the skill instructions

What you provide and what you get

Inputs and outputs
What you have	How it is used	What you get
Requirement baseline	Finds every placeholder and field context	Occurrence register
Candidate source	Shows possible values and approval state	Ready-to-confirm or no-value class
Owners and dependencies	Routes decisions and linked tests	Prioritized closure action

Cadence TBD and protocol TBC

Illustrative engineering example.

The draft ICD suggests a reporting cadence, but no approved interface decision exists. A protocol candidate also appears in a meeting note without a version record.

R-12: The unit shall report temperature every TBD seconds.
R-13: The unit shall support protocol TBC-4.
Draft ICD-2: 5 s cadence. Meeting note: protocol P version 4 proposed.

Cadence TBD and protocol TBC — illustrative output
Placeholder	Candidate and authority state	Consequence / owner decision
R-12 cadence TBD	5 s in draft ICD-2; unapproved	Blocks timed test design; interface owner approves cadence and tolerance.
R-13 protocol TBC-4	P version 4 in meeting note; unconfirmed	Blocks interoperability test; protocol owner confirms exact version.
Dependent Test T-12	No valid cadence criterion	Revise after R-12 decision; do not test against draft 5 s as final.

R-12 has a defensible candidate but is still unresolved. R-13 lacks an approved version record and should not be treated as resolved merely because “4” appears in the placeholder.

The third row is a dependent artifact rather than another placeholder. Recording it prevents a later requirement decision from leaving a stale test criterion in place.

Close the decision, then update dependents

Inventory exact placeholder occurrences, fields, and requirement revisions.
Identify the governing source, units, configuration, and candidate status.
State the narrow approval question and named decision owner.
Trace linked tests and interfaces that need revision after the decision.

Questions about this task

Is a TBC value ready to use if a draft document contains it?

It is a candidate, not a controlled decision. Keep the draft source and approval gap visible.

Should an assistant pick a reasonable cadence?

No. A numerical cadence changes performance and verification; the responsible authority must select it.

Sources and further reading

NASA Systems Engineering Handbook: Lifecycle and requirements guidance; the example decisions are illustrative.