# External Feedback Process

**Status:** live V1 review control

**Public entry point:** https://systemstheology.com/research/feedback/

## Purpose

This process turns external criticism, correction, field experience, and
specialist review into traceable decisions. It applies to every book, language,
resource, short form, research page, and production artifact in the V1
portfolio.

The process is designed to make feedback easy to integrate without pretending
that every suggestion is correct or that every reviewer endorses the work.
Submissions are evaluated by the evidence and reasoning they provide, the
reviewer's relevant competence or lived contact, and the actual scope of the
claim.

## Feedback Is Not DDF Coverage

Most feedback belongs here. Use the separate DDF coverage process only when a
proposed downstream **doctrinal** claim is absent from DDF.

Examples that remain ordinary feedback:

- a mistranslation, broken reference, factual error, or source correction;
- an exegetical or historical challenge to an existing claim;
- a scientific, clinical, legal, safeguarding, financial, or technical
  correction;
- a pastoral misuse risk;
- a localization, readability, design, accessibility, or production defect;
- a contradiction between books; or
- a recommendation to narrow, remove, or better support a claim.

If ordinary feedback shows that DDF itself is wrong, correctable, or unclear,
record and evaluate that finding here. Open a DDF coverage request only if the
proposed downstream resolution requires genuinely new doctrine beyond existing
DDF coverage.

## Stable Identity

Assign each actionable finding an ID:

```text
FB-V1-YYYY-NNN
```

Use one ID for one independently dispositionable finding. Split a submission
when its claims could receive different decisions. Mark duplicates without
discarding the additional evidence or reviewer context.

Every record must identify:

- portfolio version (`V1`);
- exact full manuscript or artifact commit;
- book, language, format, and location;
- relevant DDF Claim ID or named section, if any;
- feedback category and risk priority;
- reviewer role and relevant competence or lived contact;
- the finding, evidence, reasoning, and proposed correction;
- disposition and rationale;
- affected books, languages, resources, and public pages;
- implementation and verification commits; and
- whether a DDF coverage request was triggered.

A date, branch name, or raw line number is not an exact source identity. Raw
line numbers may assist intake, but durable records also need a heading, quoted
phrase, claim ID, page/section name, or other semantic anchor.

## Categories

Use one primary category and any necessary secondary categories:

- doctrinal;
- exegetical or original-language;
- patristic or historical;
- philosophical;
- scientific or engineering;
- psychological, clinical, or research-method;
- pastoral;
- safeguarding or abuse-response;
- legal, financial, governance, privacy, or operational;
- localization or cultural;
- editorial or accessibility;
- design or production; and
- source, rights, or attribution.

## Risk Priority

- **P0: immediate protection or legal risk:** credible danger, abuse-response
  failure, self-harm guidance defect, privacy exposure, unlawful instruction,
  or a similarly urgent issue. Restrict or correct the affected material before
  ordinary review continues.
- **P1: release blocker:** material doctrinal error, serious factual error,
  unsafe application, invalid high-stakes advice, rights problem, or a defect
  that substantially changes the work's claim.
- **P2: important:** real ambiguity, incomplete warrant, localization defect,
  cross-book inconsistency, accessibility barrier, or meaningful usability
  failure that should be resolved before stable release when applicable.
- **P3: improvement:** nonblocking clarity, craft, navigation, presentation,
  or optional expansion.

Priority describes risk and urgency, not the status or seniority of the
reviewer.

## Intake Workflow

1. **Preserve the submission.** Record the date and source without publishing
   private contact information or sensitive case material.
2. **Triage safety and privacy first.** Escalate P0 material immediately.
   Remove credentials, identifying pastoral details, protected health
   information, and unnecessary personal data from repository records.
3. **Normalize the finding.** Assign a stable ID, exact snapshot, category,
   location, claim, evidence, and requested outcome.
4. **Check for duplicates and dependencies.** Link related findings rather than
   merging away distinct evidence.
5. **Route by competence.** The decision owner seeks suitable review for the
   claim type. No reviewer has universal jurisdiction.
6. **Investigate.** Return to primary sources, original languages, current
   domain evidence, strongest rivals, and actual reader or field consequences
   as appropriate.
7. **Decide.** Record one disposition and a reason that answers the strongest
   form of the finding.
8. **Propagate.** Identify every dependent book, language, resource, short form,
   research page, and build artifact.
9. **Implement and verify.** Record the implementation commit and the tests,
   builds, review, or source checks that confirm the outcome.
10. **Close or reopen.** Close only when the recorded disposition is complete.
    Reopen under the same ID if the implementation fails or new evidence
    materially changes the finding.

## Dispositions

- **Accepted:** the finding is correct and the proposed correction is adopted
  substantially as submitted.
- **Accepted with modification:** the defect is real, but a different or
  narrower correction is more accurate.
- **Duplicate:** another finding already owns the defect; link the evidence to
  that ID.
- **Deferred:** the finding is credible but cannot yet be resolved. State the
  dependency, risk owner, and condition for reconsideration.
- **Declined:** the finding does not warrant a change. State the evidence and
  reasoning; do not use status, tone, tradition, AI agreement, or authorial
  preference as a substitute for an answer.
- **Out of scope:** the submission concerns a different work or a claim the
  portfolio does not make. Route it where possible.
- **Withdrawn:** the reviewer withdrew the finding. Preserve the audit fact
  without publishing private reasoning.

Silence is not a disposition.

## Decision And Independence Rules

The portfolio owner is accountable for final editorial and release decisions.
Specialist claims should not be closed against a qualified challenge without
competent counter-review or a clearly sufficient primary-source answer.

- Reviewers may examine one claim without endorsing the portfolio.
- Internal AI review must be labeled internal and is not external peer review.
- Model consensus is not a disposition rationale.
- A pastor does not automatically decide a clinical claim; a clinician does not
  automatically decide doctrine; an engineer does not automatically decide
  history.
- Lived experience can identify misuse, exclusion, burden, or harm that an
  abstract audit missed. Evaluate it seriously without converting one account
  into a universal empirical rate.
- Conflicts of interest and prior involvement should be recorded.

## Permission, Confidentiality, And Attribution

The website does not present its public chapter comments as formal or private
review intake. Those comments are visible to readers and display the poster's
public account identity. They have no confidentiality guarantee and must not be
used for sensitive cases, private contact details, or material that requires
controlled handling.

Formal reviewers, language collaborators, and people with sensitive
corrections make first contact through the private contact route linked from
the public feedback page. The current route uses Elijah Faviel's established
author account at <https://www.instagram.com/favihat/>; the third-party
platform's own privacy and retention terms apply. This is an onboarding route,
not an emergency, abuse-reporting, legal, medical, or pastoral service.

After contact, record explicit choices before publishing attribution or review
material:

- public name, role, and affiliation, or no public attribution;
- permission to quote the submission or publish an edited summary;
- permission to contact the reviewer for follow-up; and
- relevant competence, review scope, snapshot, and conflicts of interest.

Repository records omit private identity and contact information. Participation
is never represented as endorsement. Attribute an idea, quotation, review, or
affiliation only within the permission given.

Do not place confidential disclosures, identifiable pastoral cases, legal
communications, medical details, or unredacted abuse reports in the Git
repository. Route emergencies and mandatory reports to qualified local
channels; the feedback system is not an emergency or reporting service.

## Change Propagation

An accepted finding is incomplete until the dependency review is complete.
Check:

- the canonical English manuscript;
- Spanish and Indonesian editions;
- DDF claims and research records;
- other books that depend on the same claim;
- derivative resources and leader notes;
- short-form essays and metadata;
- public research pages, downloads, and correction notices;
- rights and translation notices; and
- generated PDF, EPUB, Kindle, and cover outputs where relevant.

Localization should not be synchronized mechanically. Propagate the governing
correction, then revise each language directly for its audience.

## Release Relationship

P0 and P1 findings block affected stable-release material until they are
resolved, removed from scope, or explicitly accepted by the release owner with
a written rationale that satisfies the V1 release gate. P2 findings require a
recorded disposition before the relevant release decision. P3 findings may
remain open when their status is clear.

The durable index is `docs/review/feedback-register.md`. Use
`docs/review/feedback-template.md` for the full working record.