# 05 — Content rules ## Status meanings | Status | Seal | Meaning | | --- | --- | --- | | Green | Filled circle | Settled. Multiple lines of evidence agree; the answer can be stated with confidence. | | Yellow | Half-filled circle | Strong case, but debated. Good evidence, yet serious scholars (including Christians) disagree, or it rests on a miracle the evidence supports but can't force. | | Red | Open ring | Open. The evidence is too thin to conclude; present it and leave it open. | For myth-busting questions (section 11), the status rates the *answer*. A Green "No" means the claim is debunked. For the "missing books" table (3B), the status rates how confident we are that leaving the book out was right. Yellow there means major Christian traditions still disagree. Only the owner sets or changes a status. ## Full article structure Every full article uses these sections, in this order. Skip a section only if it truly doesn't apply. 1. **Short answer** — two or three sentences, matching the index answer. 2. **What Scripture says** — key passages, quoted briefly, with references. 3. **What the evidence says** — history, archaeology, science, philosophy, textual criticism, as relevant. One subsection per domain. 4. **Where they meet** — how Scripture and the outside evidence fit together. 5. **What's still open** — an honest list of unresolved points and the best objections. 6. **Bottom line** — the verdict and why it has this status. 7. **Sources** — books, papers and pages used, with links where possible. ## Writing style - Plain words, short sentences, active voice. - Quote Bible passages briefly and name the translation the first time in each article. - Present opposing views in their strongest form before answering them. - Never present an estimate as a fact (example: Stoner's prophecy odds are an illustration, not measured data). - Dates: "c. 300 BC", "AD 70". En dashes for ranges: "Mark 16:9–20". ## Owner notes The index includes the owner's private notes (text starting "My Notes:" or "Note:"). They are drafting guidance for future articles. Keep them in the data as `authorNotes`, never render them publicly, and show them in dev mode only.