# DDF Coverage Request Process

**Status:** live doctrinal scope-control workflow

**Decision owner:** the current DDF maintainer or a formally designated DDF
review body. “Decision owner” does not imply that an external team already
exists.

Use this whenever a researcher, writer, editor, or module designer finds a topic that seems important but is not covered by DDF.

Live request template: `docs/research/ddf-coverage-request-template.md`
Request log: `docs/research/ddf-coverage-log.md`

## Hard Rule

No derived Systems Theology book or module should develop a claim outside DDF coverage.

If DDF does not cover the topic:

1. Stop developing the claim in the book or module.
2. Do not solve it ad hoc inside the derived project.
3. Fill out `docs/research/ddf-coverage-request-template.md` for the DDF
   decision owner.
4. Wait for a recorded existing-coverage ruling, DDF update, or rejection.
5. Resume the book or module only after the updated DDF source exists.

The derived books translate DDF. They do not expand DDF on their own.

## Stop/Go Map

Use this as the quick decision path before filling out the full request.

```mermaid
flowchart TD
  A["New claim, module, worksheet, case, or practice"] --> B["Name the governing Scripture in Hebrew, Aramaic, or Greek"]
  B --> C{"DDF covers it directly or by named pattern?"}
  C -- "Yes" --> D["Record DDF source in the book ledger"]
  C -- "No or uncertain" --> E["Stop derived writing and file a DDF request"]
  D --> F{"Claim follows DDF interpretation and scope?"}
  F -- "Yes" --> G["Draft in plain reader language"]
  F -- "No or uncertain" --> E
  G --> H["Check apostolic / ante-Nicene witness first"]
  H --> I["Use field research only for context, risk, or module design"]
  I --> J{"Could this be misused to bypass doctrine, repentance, protection, or embodied care?"}
  J -- "Yes" --> K["Add guardrails and update the source ledger"]
  J -- "No" --> L["Proceed and keep the warrant recorded"]
  K --> L
  E --> M["DDF decision owner researches, rules, updates, or rejects"]
  M --> N{"Cleared by DDF?"}
  N -- "Yes" --> D
  N -- "No" --> O["Remove the topic from the derived project"]
```

## Coverage Decision Map

Use this before drafting any new claim, module, worksheet, sidebar, or practice card.

| Step | Question | If yes | If no |
| --- | --- | --- | --- |
| 1 | Is the claim governed by original-language Scripture? | Name the controlling text, language, and term. | Remove the claim or reframe it as a limited prudential note. |
| 2 | Does DDF cover the topic directly or by a named pattern? | Record the DDF section, claim, or note in the source ledger. | Stop and file a DDF coverage request. |
| 3 | Does the claim follow DDF's interpretation? | Draft in plain reader language with DDF under the surface. | Stop and request DDF review before drafting. |
| 4 | Does apostolic or ante-Nicene witness support continuity? | Record the early witness and keep any later fathers clearly marked as support. | Recheck the claim; do not let novelty become the book's voice. |
| 5 | Is contemporary research only describing the field? | Use it for urgency, risk, or module design. | Rewrite so research does not govern doctrine. |
| 6 | Could the claim be used to bypass doctrine, repentance, protection, or embodied care? | Add guardrails in the manuscript or module. | Keep the simpler wording and record the warrant. |

If step 2 fails, no later step can rescue the claim. DDF coverage is the scope gate.

## When To File A Request

File a DDF coverage request when:

- a biblical text raises a topic not covered in DDF;
- original-language work reveals a major term or pattern DDF does not yet address;
- patristic reading surfaces a doctrine, practice, or dispute DDF does not cover;
- a pastoral or module need requires a theological claim DDF has not made;
- a reviewer asks for material that would push the book beyond DDF;
- contemporary research reveals a ministry pressure that needs theological treatment before a module can responsibly address it.

Do not file a request for:

- ordinary examples already covered by a DDF pattern;
- wording improvements;
- research statistics that only describe the field;
- denominational details that can be named as differences without becoming core claims;
- ordinary editorial, factual, localization, design, or production feedback;
  record those through `docs/review/feedback-process.md`; or
- a correction to an empirical premise. Correct the fact and assess every DDF
  and downstream claim it affects; do not use the scope gate to preserve error.

## Required Request Fields

Each request should include the information in `docs/research/ddf-coverage-request-template.md`, including:

- **Request title:** short topic name.
- **Requested by:** person or role.
- **Date:** use ISO format.
- **Affected project:** book, chapter, module, or tool.
- **Reason for request:** why the topic appeared.
- **Source trigger:** biblical text, original-language term, textual witness, patristic source, pastoral case, reviewer note, or research signal.
- **Current DDF search:** sections, claims, and notes checked.
- **Gap statement:** what DDF does not yet cover.
- **Possible DDF connection:** suspected relation to existing DDF claims.
- **Risks if handled without DDF:** doctrinal, pastoral, safety, reader, or organizational risks.
- **Needed DDF output:** new claim, revised section, appendix, note, glossary entry, or explicit rejection.
- **Source ledger impact:** which book ledger, DDF coverage-log entry, and future website source page must be updated.
- **Urgency:** low, normal, high.
- **Status:** proposed, accepted for DDF research, rejected, DDF updated, book/module cleared.

## Template

Use `docs/research/ddf-coverage-request-template.md` as the working request template. If multiple requests are open at once, copy that file into a dated note or issue-specific request file, and add the item to `docs/research/ddf-coverage-log.md`.

## Approval Rule

A book or module may use the topic only after one of these is true:

1. the DDF decision owner identifies existing DDF coverage and names the
   governing source;
2. the DDF decision owner updates DDF and points the writer to the new source;
3. the DDF decision owner rejects the topic as outside DDF, and the book or
   module removes it.

No fourth path exists.

## Ledger Rule

When the DDF decision owner clears a request, update the relevant
source-and-conclusion ledger before the derived book or module resumes. If the
topic will be visible to readers, also update the planned website source page
notes so the public trail remains recoverable.