# Detect a dependency cycle before commitment

Illustrative planning brief; no automatic product import.

Synthetic planning case: A requires the final output of B before starting. B requires the final output of C. C requires the final output of A. No accepted initial output exists.

## Decision

The three tasks have no permitted first start under the stated final-output requirements. Resolve a real boundary or initial-input change before committing the schedule.

## Owned work

- Confirm each actual input need
  - Owner role: Receiving owners
  - Acceptance evidence: All three edges mean final usable output, not informal awareness.
- Identify the circular gate
  - Owner role: Planner
  - Acceptance evidence: The A/B/C cycle and absent initial output are recorded.
- Agree a genuine break
  - Owner role: Decision owner
  - Acceptance evidence: A supported staged input or changed dependency is accepted; no edge is erased just to make a chart work.

## Workflow

1. Confirm each actual input need. Check: All three edges mean final usable output, not informal awareness.
2. Identify the circular gate. Check: The A/B/C cycle and absent initial output are recorded.
3. Agree a genuine break. Check: A supported staged input or changed dependency is accepted; no edge is erased just to make a chart work.

## Judgment

Do not confuse a start-blocking dependency cycle with an intentional iterative process or a harmless communication loop.


## Filled manual planning note

The three tasks have no permitted first start under the stated final-output requirements. Resolve a real boundary or initial-input change before committing the schedule. A→B→C→A is circular in the required-input graph. Every task has an unmet predecessor; adding dates does not supply an initial completed output. Do not confuse a start-blocking dependency cycle with an intentional iterative process or a harmless communication loop.


## Workflow questions

### Can I fix it by assigning A the earliest date?

No. Its required B output is still missing.

### Does every feedback loop prohibit work?

No. This example is specifically a circular requirement for final output before any start. Iterative workflows need different boundary definitions.

## Product connection

Use the owned checks and downloaded brief to discuss this planning decision alongside your TeamBoostAI tasks. Confirm available fields, roles and account features separately. The example is manual; it does not calculate live analytics, create work or run an experiment in the product.

Confirm account availability before adopting this manual outline.

## Original worked case

Synthetic records, manual planning only. No account import or live analytics.

### Inspect the invented case records

Task | Required completed input | Can start initially?
--- | --- | ---
A | B final output | No
B | C final output | No
C | A final output | No

### Reasoning

A→B→C→A is circular in the required-input graph. Every task has an unmet predecessor; adding dates does not supply an initial completed output.

### Bounded result

The three tasks have no permitted first start under the stated final-output requirements. Resolve a real boundary or initial-input change before committing the schedule.

### Distinct decision

The guide checks whether the declared final-input model has any executable first task.

### Limits

Do not confuse a start-blocking dependency cycle with an intentional iterative process or a harmless communication loop.

### Definitions and method context

- GAO Schedule Assessment Guide — https://www.gao.gov/products/gao-16-89g — General schedule-model context. All records, local policies and arithmetic are original toy examples, not a certified or optimized schedule.