Every TBD in Your ICD Has Already Been Filled In

Every TBD in your ICD already has a value. An engineer downstream needed the number this sprint, could not wait for your review board, asked around, and wrote one into a header file. The field is filled. You don't know with what, and neither does the vendor on the other side of the interface.

Every space program runs a TBD table. The NASA Systems Engineering Handbook is direct about how to keep it honest: minimize TBDs, and where a value cannot be settled, put a best estimate in and mark it TBR, with the rationale, the person responsible for eliminating it, and the date by which it must be eliminated. NASA tracks TBD and TBR counts as a leading indicator across requirements and interface documents. The count is supposed to fall as the design matures, and to sit near zero by CDR.

The guidance is right. It also measures one thing: the discipline of the people writing the document. It says nothing about the people reading it.

The count falls whether or not anyone decided anything

A TBD leaves a closure table in four ways. Someone makes the call and records it. Someone deletes the field because the component that needed it got descoped. Someone replaces it with the number from an analysis that nobody has re-run since the trade study. Or someone enters the value the software has been using since March, because that is what everyone assumed anyway.

All four decrement the count. One of them is a decision. The other three are your team managing the count rather than defining the interface, and from the outside they look identical: same green trend line into CDR, same slide in the review package.

We have sat in the meeting where a TBD closed at the value the flight software had already shipped with, and the room treated it as a closure instead of a finding. Nobody was lying. The number in the code was the only number anyone had, so it became the number in the document. A developer with a deadline decided that interface in February. A board that thought it was deciding ratified it in September.

Between the TBD and its due date, the interface ships anyway

A payload housekeeping rate is TBD, owner payload systems, close by PDR. That is a reasonable entry in a reasonable table. Meanwhile the flight software team needs a ring buffer size this sprint, because the board layout needs the memory map, because the parts order has a lead time. They ask around. Somebody remembers 10 Hz from a call in February. They size for 10 Hz and move on.

# ICD rev C, table 4-2
payload_hk_packet:
  rate_hz:      TBD    # TBD-114, owner: payload SE, close by PDR
  length_bytes: 96
  epoch:        TBD    # TBD-115, owner: GNC, close by CDR

# ICD rev C, table 4-2
payload_hk_packet:
  rate_hz:      TBD    # TBD-114, owner: payload SE, close by PDR
  length_bytes: 96
  epoch:        TBD    # TBD-115, owner: GNC, close by CDR

# ICD rev C, table 4-2
payload_hk_packet:
  rate_hz:      TBD    # TBD-114, owner: payload SE, close by PDR
  length_bytes: 96
  epoch:        TBD    # TBD-115, owner: GNC, close by CDR

/* flight software, written the week rev C shipped */
#define HK_RATE_HZ  10   /* per call with payload, 12 Feb */
#define HK_RING_LEN 32   /* 3.2 s of margin at 10 Hz. plenty. */

/* flight software, written the week rev C shipped */
#define HK_RATE_HZ  10   /* per call with payload, 12 Feb */
#define HK_RING_LEN 32   /* 3.2 s of margin at 10 Hz. plenty. */

/* flight software, written the week rev C shipped */
#define HK_RATE_HZ  10   /* per call with payload, 12 Feb */
#define HK_RING_LEN 32   /* 3.2 s of margin at 10 Hz. plenty. */

The document says TBD. The build says 10. The build wins, because the build is the thing that runs. When the rate lands at 50 Hz eight months later, the closure gets recorded as on-time and green, and the overflow surfaces during integration as intermittent packet loss that takes three weeks to trace back to a constant someone defined before anyone had the right to define it.

The vendor on the other side did the same arithmetic against the same TBD and got a different answer. Neither of you misread the document. The document said nothing.

A TBD stops nobody from picking a value. It only stops them from telling you which one.

Your standard will freeze an ICD with the guesses still in it

ECSS-E-ST-10-24C sets out how interfaces get identified, controlled, and verified. A controlled ICD carries the signature of the interface responsible. A frozen ICD carries the signature of the interface responsible and every involved actor. TBD means to be defined; TBC means to be confirmed; both are legitimate entries in a document at those maturity levels.

So a frozen ICD, signed by every party to the interface, can carry three TBCs. Those three fields have values in somebody's code today. The signature ceremony does not touch them. Everyone signed an agreement about the fields where they already agreed, plus three arguments they have not had yet, each one settled in private by whichever team hit its deadline first.

Configuration control is not the gap. The gap is that the document format lets an undefined field sit next to a defined one and look the same: a row in a table, a line in a PDF, equally frozen, equally signed.

A schema cannot hold a TBD

A document can never fix this, which is why we think the artifact has the job backwards.

In a document, TBD is a word. It sits in a cell, it reads fine, it passes review, and no tool downstream can see it, because there are no tools downstream. There is a person reading a PDF and typing a number into C. In a schema, there is no TBD type. A field has a byte order or it does not parse. A rate has a number or the scheduler will not build.

That constraint is the useful part. Make the unresolved state structural rather than editorial:

payload_hk_packet:
  rate_hz:
    unresolved:    TBD-114
    owner:         payload-se
    close_by:      PDR
    best_estimate: 10        # call, 12 Feb. Estimate, not agreement.

payload_hk_packet:
  rate_hz:
    unresolved:    TBD-114
    owner:         payload-se
    close_by:      PDR
    best_estimate: 10        # call, 12 Feb. Estimate, not agreement.

payload_hk_packet:
  rate_hz:
    unresolved:    TBD-114
    owner:         payload-se
    close_by:      PDR
    best_estimate: 10        # call, 12 Feb. Estimate, not agreement.

Generate the decoder and it fails. Generate the ground checkout equipment and it fails. Generate the ICD and the table prints the field as unresolved with its owner and its date, which is what NASA asked for in the first place. The best estimate stays, because a number with rationale beats a blank, but nobody builds against it by accident. To ship, a team either closes the TBD or writes an explicit override, and the override is a line in a file with an author, a date, and a diff that shows up in the next review. The teams who need the number still get to move. They can't move silently.

Accept this and your closure table turns into a list of every place the program is currently running on a guess. That number climbs before it drops, because the first honest pass surfaces the assumptions that were already load-bearing. Most programs would rather have the smooth line. The smooth line is why integration takes twice as long as the plan says it will.

Your TBD count measures what you have admitted is undefined. It says nothing about the fields that got defined months ago by whoever needed them first, in a header file that nobody sends to the vendor. Write the interface somewhere a guess cannot pass for a decision, or keep signing frozen documents over arguments you have not had.