<!-- informative -->

# Deferred Design

## Alternatives

Alternative branches require explicit choice semantics.

### Alternative group

```yaml
alternative_group:
  id: ALT-001
  objective: "Select extraction strategy"
  members:
    - NODE-rule-based
    - NODE-model-based
    - NODE-hybrid
  execution_mode: PROGRESSIVE
  selection_authority: NODE-extraction-controller
  selection_criteria:
    - accuracy
    - latency
    - operating_cost
  fallback_order:
    - NODE-hybrid
    - NODE-rule-based
  budget_id: BUDGET-ALT-001
  losing_branch_policy: PRESERVE_EVIDENCE_AND_CANCEL
```

### Execution modes

- SEQUENTIAL
- SPECULATIVE
- PROGRESSIVE
- COMPARATIVE
- CONDITIONAL

Alternative nodes must not all run merely because their ordinary dependencies are satisfied.

### Rejected alternatives

Rejected alternatives and their evidence should normally be retained. Possible states:

- NOT_SELECTED
- REJECTED
- SUPERSEDED
- CANCELLED
- RETAINED_FOR_FALLBACK

Dependants of rejected outputs must be invalidated, cancelled, or explicitly rebound.

## Multi-Model Routing

Models should be selected by profiles rather than hard-coded names.

### Model profile

```yaml
model_profile:
  id: CODE_SPECIALIST
  capabilities:
    - REPOSITORY_NAVIGATION
    - IMPLEMENTATION
    - TEST_GENERATION
  tool_access:
    - FILESYSTEM
    - SHELL
  context_capacity: LARGE
  structured_output_reliability: HIGH
  data_classes:
    - PUBLIC
    - INTERNAL
  independence_group: PROVIDER_A
  concurrency_limit: 3
  cost_class: MEDIUM
  observed_performance: {}
```

Reject a model if it:

- is not permitted to receive the data;
- lacks required tools;
- lacks sufficient context;
- cannot meet the required output schema;
- exceeds concurrency or budget;
- fails an independence requirement;
- has a relevant reliability restriction.

### Selection

Where possible, deterministic rules select the executor. Semantic routing should be used only when rule-based selection
leaves a meaningful unresolved choice. Record verified performance by task type for future routing.

Independent evaluation is documented in [Independent evaluation](validation.md#independent-evaluation).

## Evolving Project Description

The initial project description should remain minimal but sufficient to preserve direction and safety.

### Project kernel

The project kernel is maintained in the [experiment manifest](experiment.md#project-kernel) and comprises:

### Rolling-wave detail

Use asymmetric detail:

- project horizon: coarse and stable;
- near-term work: moderately detailed and revisable;
- active nodes: precise contracts and acceptance criteria.

### Evidence-backed evolution

Update project knowledge because execution, validation, stakeholder input, or experiments provide evidence. Maintain:

- decision log;
- assumption register;
- risk register;
- evidence register;
- contract history;
- artefact lineage;
- invalidation history.

Every assumption should record:

- confidence;
- impact if wrong;
- reversibility;
- validation method;
- latest responsible resolution point.