{
  "schema_version": "ai_bible_commentary_prompt_json_v3_restored_order",
  "id": "project-plans-protocols-manifest-bundle-prompt",
  "title": "Project Plans Protocols Manifest Bundle Prompt",
  "menuTitle": "Project Plans Protocols Manifest Bundle Prompt",
  "group": "research",
  "group_label": "RESEARCH",
  "position": 31,
  "canonical_page_url": "https://ai-bible-commentary.com/prompts-library/#project-plans-protocols-manifest-bundle-prompt",
  "source_prompt_file": "prompts/project-plans-protocols-manifest-bundle-prompt.md",
  "prompt_text": "MANDATORY PROTOCOL COMPLIANCE AND REQUIREMENT-COVERAGE CONTROL LAYER\n\nThis entire section is mandatory for every project governed by this\nmaster prompt.\n\nIts purpose is to prevent a recurring class of project failure:\n\nA complete governing protocol exists, but a derived prompt, shortened\nworkflow, local validator, checkpoint sequence, convenience procedure,\nor handoff gradually becomes the practical operating authority and\nsilently omits mandatory requirements.\n\nThe project architecture must prevent this.\n\nThe governing protocol must not merely exist as documentation.\n\nIts mandatory requirements must be: - enumerated; - machine-readable\nwhere practical; - mapped to the active workflow; - globally\nvalidated; - dependency-gated; - checked at handoff; - checked before\nevery major execution step; - checked before release; - checked before\nclosure.\n\nA project must never depend on conversational memory or operator\nrecollection to preserve mandatory requirements.\n\n1.  FUNDAMENTAL NON-SUPERSESSION RULE\n\nEstablish this rule at project creation:\n\nNo derivative artifact may supersede, narrow, omit, reinterpret,\nreorder, waive, weaken, or replace a requirement contained in a\nhigher-authority governing artifact unless an explicit approved\nchange-control action modifies the governing requirement itself.\n\nThis applies to: - starter prompts; - next-step prompts; - phase\nprompts; - pilot prompts; - batch prompts; - operator instructions; -\ncheckpoint instructions; - book/module-specific workflows; - scripts; -\nvalidators; - wrappers; - manifests; - README files; - handoff\ninstructions; - deployment procedures; - automated state machines; -\nconvenience summaries; - AI-generated instructions.\n\nA derivative artifact may specify how to execute the current permitted\noperation.\n\nIt may not redefine which operations are required by the project.\n\n2.  FORMAL AUTHORITY HIERARCHY\n\nEvery project must define a formal authority hierarchy.\n\nUnless the project requires another hierarchy, use:\n\nLEVEL 1 — FROZEN GOVERNING REQUIREMENTS ↓ LEVEL 2 — APPROVED AMENDMENTS\n/ CHANGE CONTROL ↓ LEVEL 3 — CANONICAL REQUIREMENT REGISTER ↓ LEVEL 4 —\nCANONICAL PROJECT STATE MACHINE / MASTER WORKFLOW ↓ LEVEL 5 — GLOBAL\nVALIDATORS AND GATES ↓ LEVEL 6 — PHASE / MODULE / BOOK / BATCH PROTOCOLS\n↓ LEVEL 7 — STARTER PROMPTS / NEXT-STEP PROMPTS ↓ LEVEL 8 — OPERATOR\nNOTES / CONVENIENCE INSTRUCTIONS\n\nLower levels are subordinate to all higher levels.\n\nIf two artifacts conflict, the higher-authority artifact governs unless\nthere is an approved amendment explicitly changing it.\n\nA newer timestamp does not automatically confer greater authority.\n\nA filename containing words such as FINAL, MASTER, CURRENT, LATEST, or\nAUTHORITATIVE does not itself confer authority.\n\nAuthority must be recorded explicitly in project control files.\n\n3.  CANONICAL PROTOCOL REQUIREMENT REGISTER\n\nEvery substantial governed project must materialize its governing\nrequirements into a canonical requirement register.\n\nRecommended filename: PROJECT_PROTOCOL_REQUIREMENTS.json\n\nor, where versioning is appropriate: _PROTOCOL_REQUIREMENTS_vX.Y.json\n\nThis register is not merely a general requirements list.\n\nIt must contain every mandatory operation, gate, output, validation\nrequirement, and closure requirement contained in the governing protocol\nand approved amendments.\n\nEach requirement must receive a stable unique ID, such as: PCR-001\nPCR-002 PCR-003\n\nFor every requirement record at minimum: - Requirement_ID -\nRequirement_Name - Requirement_Description - Requirement_Type -\nMandatory_or_Optional - Governing_Source - Governing_Source_Section -\nPhase - Required_Predecessors - Required_Output - Validation_Method -\nRequired_Status - Waivable - Amendment_ID_if_modified - Current_Status -\nEvidence_Artifact - Completion_Date - Notes\n\nPossible Requirement_Type values include: OPERATION OUTPUT QA_GATE\nDEPENDENCY TRACEABILITY SOURCE_CONTROL SCHEMA HANDOFF RELEASE CLOSURE\nPRESERVATION\n\nNo mandatory governing requirement may exist only in prose while being\nabsent from the canonical requirement register unless a documented\nreason makes machine-readable representation impractical.\n\n4.  REQUIREMENT EXTRACTION AUDIT\n\nWhen the protocol requirement register is first created, independently\naudit it against the complete governing protocol.\n\nDo not assume the first extraction is complete.\n\nPerform:\n\nGOVERNING PROTOCOL ↓ INDEPENDENT REQUIREMENT EXTRACTION ↓ CANONICAL\nREQUIREMENT REGISTER ↓ LINE-BY-LINE / SECTION-BY-SECTION COVERAGE AUDIT\n\nThe audit must answer: 1. Has every mandatory protocol clause been\nrepresented? 2. Has every mandatory output been represented? 3. Has\nevery prerequisite been represented? 4. Has every gate been represented?\n5. Has every required QA activity been represented? 6. Has every handoff\nrequirement been represented? 7. Has every release requirement been\nrepresented? 8. Has every closure requirement been represented? 9. Has\nany requirement been weakened during conversion? 10. Has any requirement\naccidentally been made optional?\n\nThe requirement register may not become authoritative until this\nextraction audit passes.\n\n5.  CANONICAL PROTOCOL COVERAGE MATRIX\n\nEvery project must maintain a current protocol coverage matrix.\n\nRecommended filename: PROTOCOL_COVERAGE_MATRIX.csv\n\nAt minimum include: Requirement ID | Requirement | Mandatory | Current\nStatus | Evidence | Blocking\n\nThe actual requirements must be derived from the project itself.\n\nThe matrix must expose missing mandatory work visibly.\n\nA project may not use a simplified phase list if that list conceals\nmandatory requirements from this matrix.\n\n6.  CANONICAL STATE MACHINE\n\nCreate a canonical project state machine derived from the requirement\nregister.\n\nRecommended filename: CANONICAL_WORKFLOW_STATE_MACHINE.json\n\nIt must define: - all mandatory states; - legal transitions; - required\npredecessor states; - blocking conditions; - required outputs; -\nrequired QA gates; - terminal states.\n\nIf some phases may execute in parallel, model that explicitly.\n\nThe canonical state machine—not the most recently generated starter\nprompt—defines permitted project progression.\n\n7.  NO DERIVATIVE WORKFLOW MAY DEFINE THE MASTER SEQUENCE\n\nStarter prompts, module prompts, book prompts, batch prompts, and\ncheckpoint prompts may reference the next expected operation.\n\nHowever, they must never become the source from which the project\ndetermines the complete production sequence.\n\nEvery derivative prompt must contain language equivalent to:\n\nSUBORDINATION RULE\n\nThis prompt is subordinate to the frozen governing protocol, approved\namendments, canonical protocol requirement register, and canonical\nproject state machine.\n\nThis prompt may narrow the immediate operation being performed, but it\nmay never omit, reorder, waive, reinterpret, weaken, or supersede a\nmandatory governing requirement.\n\nBefore executing this prompt, validate the proposed operation against\nthe canonical requirement register and state machine.\n\nIf this prompt conflicts with either, STOP. The governing protocol and\ncanonical requirement system control.\n\nThis rule is mandatory.\n\n8.  STARTER PROMPTS MUST NOT DECLARE THEIR OWN SUCCESSORS\n\nA derivative starter prompt may state an anticipated next operation only\nif that operation is independently derived from the canonical state\nmachine.\n\nIt must not contain an unconditional statement such as: After this\nstage, perform Stage 8.\n\nunless the global state machine proves that Stage 8 is actually the next\npermitted state.\n\nInstead use:\n\nAfter successful completion, consult the canonical requirement register\nand state machine to determine the next permitted operation. The\nanticipated next operation is [X], subject to global compliance\nvalidation.\n\nThe project must determine NEXT STEP from GLOBAL REQUIREMENTS + CURRENT\nPASS STATE, not from LAST STARTER PROMPT + LOCAL SEQUENCE.\n\n9.  GLOBAL NEXT-STEP RESOLUTION\n\nBefore every major governed operation, compute or explicitly determine\nthe next permitted operation from the complete project requirement\nsystem.\n\nCURRENT STATE + CANONICAL REQUIREMENT REGISTER + APPROVED AMENDMENTS +\nDEPENDENCY GRAPH + PASS/FAIL STATE ↓ NEXT PERMITTED OPERATION\n\nDo not simply ask: “What did the previous starter prompt say comes\nnext?”\n\nAsk instead: “Given every mandatory requirement in the governing\nprotocol, what is the earliest legally executable incomplete operation?”\n\nIf those answers differ, the previous starter prompt is defective and\nmust not be followed.\n\n10. PRE-EXECUTION GLOBAL COMPLIANCE GATE\n\nBefore beginning every major phase, pilot, module, book, batch, release,\nexport, deployment, or closure step, run a Pre-Execution Global\nCompliance Gate.\n\nThis gate must verify: 1. The requested step exists in the canonical\nstate machine. 2. All required predecessors are PASS. 3. No mandatory\nintermediate requirement remains NOT_STARTED or FAILED if it blocks this\nstep. 4. Required authoritative inputs exist. 5. Required\nschemas/registries are current. 6. The local prompt does not conflict\nwith the governing protocol. 7. No approved amendment has changed the\nsequence. 8. No known blocking defect remains open. 9. The proposed\noperation is the next permitted operation or is otherwise legally\nexecutable in parallel. 10. The operation does not silently skip a\nmandatory protocol layer.\n\nIf any blocking test fails: PRE-EXECUTION GLOBAL COMPLIANCE GATE = FAIL\n\nThe step must not proceed.\n\n11. GLOBAL VERSUS LOCAL VALIDATION\n\nEvery substantial project must distinguish:\n\nLOCAL VALIDATION: “Was this particular stage performed correctly?”\n\nGLOBAL PROTOCOL VALIDATION: “Is the whole project still progressing in\ncompliance with every mandatory governing requirement?”\n\nA local validator may return errors=0 and warnings=0 and the project may\nstill be globally non-compliant.\n\nTherefore: LOCAL PASS DOES NOT IMPLY GLOBAL PASS.\n\nEvery major stage promotion must require both: LOCAL QA = PASS AND\nGLOBAL PROTOCOL COMPLIANCE = PASS\n\n12. GLOBAL PROTOCOL COMPLIANCE VALIDATOR\n\nFor substantial projects, create a dedicated validator.\n\nRecommended name: validate_global_protocol_compliance.py\n\nIts purpose is not to validate detailed stage contents. Its purpose is\nto enforce protocol completeness.\n\nAt minimum it should test: - canonical requirement register present; -\nall mandatory requirements represented; - active state machine agrees\nwith requirement register; - current stage valid; - required\npredecessors PASS; - prohibited successors BLOCKED; - mandatory outputs\npresent where required; - no mandatory requirement silently removed; -\nno local workflow contradicts global state; - no release/export begins\nprematurely; - no closure begins prematurely; - approved amendments\nincorporated.\n\nWhere automation is impossible, perform the same checks explicitly and\npreserve the audit evidence.\n\n13. GLOBAL GATING RULE\n\nEvery mandatory downstream operation must identify all blocking\npredecessors, not merely the immediately previous numbered stage.\n\nWhere possible, calculate this automatically from the dependency graph.\n\n14. NO TRANSITIVE-ASSUMPTION SHORTCUT\n\nDo not assume: “If Stage 7 passed, all earlier requirements must\ntherefore have passed.”\n\nThat assumption is prohibited unless the state machine mechanically\nguarantees it and has itself passed protocol-semantic validation.\n\nEvery major release, export, deployment, and closure gate should\nindependently query the complete required predecessor set.\n\n15. MANDATORY REQUIREMENT CANNOT DISAPPEAR THROUGH SUMMARIZATION\n\nWhenever a protocol is summarized, compressed, converted to a starter\nkit, moved to a new chat, or reduced into an operational checkpoint, the\nfollowing rule applies:\n\nCompression may remove redundant explanation, historical material, or\nnon-operational evidence, but it may never remove an active mandatory\nrequirement or its governing reference.\n\nLean checkpoints may be small.\n\nThey may not be semantically incomplete.\n\nThe canonical requirement register and active coverage matrix therefore\nbelong in the minimum safe operational set for substantial governed\nprojects.\n\n16. REQUIREMENT-INHERITANCE GATE FOR DERIVATIVE ARTIFACTS\n\nBefore promoting any newly generated protocol, starter prompt, workflow,\nstate machine, validator, checkpoint, handoff, or operator guide to\noperational use, perform a requirement-inheritance test.\n\nAsk: 1. Which higher-authority requirements govern this artifact? 2.\nDoes the derivative preserve every requirement relevant to its scope? 3.\nDoes it accidentally imply that omitted requirements no longer exist? 4.\nDoes it redefine any successor state? 5. Does it weaken any gate? 6.\nDoes it make an optional step appear mandatory? 7. Does it make a\nmandatory step appear optional? 8. Does it alter authority\nrelationships? 9. Does it introduce a shortcut? 10. Does it retain\nlinks/references to the governing protocol?\n\nOnly after PASS may the derivative artifact become active.\n\n17. DERIVATIVE PROMPT DIFF / SEMANTIC COMPLIANCE REVIEW\n\nWhen an important operational prompt is generated from a larger\ngoverning protocol, perform a semantic compliance review.\n\nCheck for: - omitted mandatory requirements; - weakened wording; -\naltered dependency rules; - changed sequence; - shortened downstream\nflow; - missing validation gates; - missing required outputs; - missing\nstop conditions; - changed authority.\n\nA concise prompt is acceptable.\n\nA semantically narrower governing system is not.\n\n18. VALIDATOR AUTHORITY LIMIT\n\nEvery stage-specific validator must declare its scope.\n\nExample:\n\nVALIDATOR SCOPE: Validates Stage 6 content only.\n\nTHIS VALIDATOR DOES NOT: Establish permission to begin Stage 7, Stage 8,\nrelease, or closure.\n\nNEXT-STATE AUTHORIZATION: Must come from the Global Protocol Compliance\nValidator.\n\nA local validator is prohibited from granting project-level progression\nauthority unless specifically designed as the global validator.\n\n19. NO ZERO-ERROR FALLACY\n\nThe following inference is prohibited:\n\nerrors=0 warnings=0 therefore project is complete\n\nA validator output is meaningful only within its declared validation\nscope.\n\nProject status must record both: LOCAL_STAGE_QA\nGLOBAL_PROTOCOL_COMPLIANCE\n\nExample: LOCAL_STAGE_QA: PASS GLOBAL_PROTOCOL_COMPLIANCE: FAIL\nPROJECT_PROGRESS_AUTHORIZED: NO\n\n20. SEMANTIC COMPLETENESS AUDIT\n\nIntroduce a formal PROTOCOL_SEMANTIC_COMPLETENESS_AUDIT.\n\nThis audit is different from checksum audit, ZIP audit, manifest audit,\nfile-integrity audit, and schema audit.\n\nIts purpose is to determine whether the active operational system still\nrepresents the complete governing protocol.\n\nIt must answer: 1. Does the active requirement register contain every\ncurrent mandatory requirement? 2. Does the state machine contain every\nmandatory operation? 3. Does the dependency graph prevent prohibited\nskipping? 4. Does the active next-step instruction agree with the state\nmachine? 5. Have any mandatory outputs disappeared? 6. Have any global\ngates been weakened? 7. Has any convenience workflow become normative\nwithout amendment? 8. Has any local validator accidentally assumed\nglobal authority? 9. Has any old prompt been retained even though its\nworkflow assumptions are obsolete? 10. Have all approved amendments been\nincorporated? 11. Are all mandatory incomplete requirements visible? 12.\nCould the current workflow reach release or closure while any mandatory\nrequirement remains incomplete?\n\nThe answer to Question 12 must be NO or the architecture fails.\n\n21. TWO-AUDIT HANDOFF REQUIREMENT\n\nEvery major operational handoff must pass two independent audit\nfamilies.\n\nAUDIT A — ARTIFACT INTEGRITY AUDIT Checks files present, hashes, ZIP\ncontents, manifests, filenames, required workbook/data files, scripts,\nschemas, checkpoint files, non-corruption, and internal file references.\n\nThis answers: “Did we preserve the artifacts correctly?”\n\nAUDIT B — PROTOCOL SEMANTIC AUDIT Checks every mandatory protocol\nrequirement still represented, active state machine complete, next-step\ninstruction correct, mandatory incomplete work visible, local prompts\nsubordinate, no omitted phases, no weakened gates, no unauthorized\nshortcut, and global validator current.\n\nThis answers: “Does the preserved operational system still force the\ncomplete project requirements?”\n\nA handoff must not be declared operationally safe unless: ARTIFACT\nINTEGRITY AUDIT = PASS AND PROTOCOL SEMANTIC AUDIT = PASS\n\n22. NEW-CHAT RECONSTRUCTION TEST\n\nAt the beginning of every new-chat continuation of a substantial\nproject: 1. Identify the highest-authority governing protocol. 2.\nIdentify all approved amendments. 3. Load the canonical requirement\nregister. 4. Reconstruct the mandatory workflow from the governing\nrequirements. 5. Compare reconstructed workflow to the active canonical\nstate machine. 6. Compare the state machine to the active next-step\nprompt. 7. Compare required predecessor states to recorded project\nstate. 8. Identify every mandatory requirement currently PASS,\nIN_PROGRESS, NOT_STARTED, BLOCKED, FAILED, or\nWAIVED_BY_APPROVED_AMENDMENT. 9. Determine the next permitted operation\nindependently. 10. Only then begin production.\n\nDo not simply trust the previous chat’s statement: “Next step: X.”\nVerify it.\n\n23. HANDOFF STARTER PROMPT SAFEGUARD\n\nEvery new-chat starter prompt must contain:\n\nMANDATORY AUTHORITY CHECK\n\nDo not treat this starter prompt as the governing project protocol.\n\nBefore executing its proposed next step: 1. identify the frozen\ngoverning protocol and approved amendments; 2. inspect the canonical\nrequirement register; 3. inspect the canonical workflow state machine;\n4. run or perform the global protocol compliance check; 5. independently\nverify that the proposed next step is permitted.\n\nIf this starter prompt conflicts with any higher-authority governing\nartifact, the starter prompt is wrong.\n\nSTOP and resolve the discrepancy before production.\n\n24. ACTIVE WORKFLOW COVERAGE REPORT\n\nAt every major checkpoint, produce a compact coverage report containing\nat minimum:\n\nMANDATORY REQUIREMENTS TOTAL: PASS: IN PROGRESS: NOT STARTED: BLOCKED:\nFAILED: WAIVED BY APPROVED AMENDMENT:\n\nEARLIEST INCOMPLETE MANDATORY REQUIREMENT: NEXT PERMITTED OPERATION:\nPROPOSED NEXT OPERATION: MATCH: YES / NO\n\nGLOBAL PROTOCOL COMPLIANCE: PASS / FAIL\n\nIf MATCH = NO, do not continue until reconciled.\n\n25. NO CONVENIENCE SHORTCUT MAY BECOME NORMATIVE\n\nA temporary shortcut may sometimes be useful.\n\nBut the project must distinguish TEMPORARY OPERATOR CONVENIENCE from\nGOVERNING WORKFLOW CHANGE.\n\nNo shortcut becomes normative merely because: - it has been used\nrepeatedly; - later prompts copied it; - several checkpoints contain\nit; - no validator complained; - operators became accustomed to it.\n\nA permanent workflow change requires formal change control and amendment\nof the governing requirement system.\n\n26. DRIFT DETECTION\n\nEstablish a Protocol Drift Audit.\n\nCompare periodically:\n\nGOVERNING PROTOCOL vs REQUIREMENT REGISTER vs STATE MACHINE vs CURRENT\nPHASE PROTOCOL vs STARTER PROMPT vs VALIDATORS vs PROJECT STATE\n\nLook specifically for missing requirements, sequence changes, scope\nnarrowing, weakened gates, renamed requirements that lost meaning, local\nrules becoming global, global rules disappearing locally, obsolete\ninstructions, and undocumented amendments.\n\nAny unexplained divergence is a defect.\n\n27. GOVERNANCE CHECKSUMS ARE NOT ENOUGH\n\nChecksums prove file identity.\n\nThey do not prove that the file contains the correct governing logic.\n\nTherefore: Cryptographic integrity must never be treated as semantic\ncorrectness.\n\nSimilarly: - manifest consistency does not prove protocol\ncompleteness; - file presence does not prove requirement coverage; -\nsuccessful ZIP extraction does not prove operational correctness; -\nlocal QA does not prove project-level compliance.\n\n28. MACHINE-READABLE DEPENDENCY GRAPH\n\nWhere feasible, materialize mandatory dependencies in a machine-readable\ndependency graph.\n\nDo not rely solely on human-readable arrows or stage numbering.\n\nThe global validator should use this dependency graph.\n\n29. RELEASE GATE MUST QUERY GLOBAL REQUIREMENTS\n\nBefore final export, public release, deployment, publication, or project\nclosure, run a complete mandatory-requirement query.\n\nThe release gate must fail if any mandatory requirement is NOT_STARTED,\nIN_PROGRESS, BLOCKED, or FAILED unless that requirement has been\nformally removed or waived by an approved amendment.\n\nThe fact that the immediately previous stage passed is insufficient.\n\n30. CLOSURE GATE\n\nResearch/project closure must require:\n\nALL MANDATORY REQUIREMENTS = PASS OR FORMALLY WAIVED / REMOVED BY\nAPPROVED AMENDMENT\n\nplus all required final QA.\n\nClosure must not be inferred from final export existing, deployment\nsucceeding, final prose being complete, last numbered stage passing, or\nhandoff package being complete.\n\n31. PROHIBIT FALSE FINALITY IN DERIVATIVE ARTIFACTS\n\nA local artifact must not describe itself as FINAL, FINAL QA, FINAL\nSTAGE, PROJECT COMPLETE, RESEARCH CLOSED, or READY FOR EXPORT merely\nbecause it is final within its local scope.\n\nUse qualified language such as: FINAL WITHIN PHASE 6 LOCAL QA COMPLETE\nSUBJECT TO GLOBAL PROTOCOL COMPLETION\n\nunless global compliance has actually been established.\n\n32. GLOBAL REQUIREMENT COUNT\n\nWhere the governing protocol has a finite set of mandatory requirements,\ntrack:\n\nTOTAL_MANDATORY_REQUIREMENTS TOTAL_PASS TOTAL_INCOMPLETE\n\nThese counts should reconcile with the protocol coverage matrix.\n\nUnexpected reduction in TOTAL_MANDATORY_REQUIREMENTS is a governance\nwarning and must be investigated.\n\nA new checkpoint must not silently contain fewer mandatory requirements\nthan its predecessor unless an approved amendment explains the\ndifference.\n\n33. REQUIREMENT-SET INHERITANCE CHECK\n\nAt each major checkpoint compare: PREVIOUS_MANDATORY_REQUIREMENT_SET vs\nCURRENT_MANDATORY_REQUIREMENT_SET\n\nClassify differences as: UNCHANGED ADDED_BY_APPROVED_AMENDMENT\nMODIFIED_BY_APPROVED_AMENDMENT REMOVED_BY_APPROVED_AMENDMENT\nUNEXPLAINED_DIFFERENCE\n\nAny UNEXPLAINED_DIFFERENCE causes FAIL.\n\n34. CHECKPOINT COMPLIANCE SNAPSHOT\n\nEvery governed checkpoint should preserve, where applicable:\n\nPROJECT_PROTOCOL_REQUIREMENTS. PROTOCOL_COVERAGE_MATRIX.\nCANONICAL_WORKFLOW_STATE_MACHINE. APPROVED_AMENDMENTS.\nGLOBAL_PROTOCOL_QA. CURRENT_PROJECT_STATE. NEXT_STEP.*\n\nThese files are part of the minimum safe checkpoint for complex\nprojects.\n\n35. MINIMUM SAFE HANDOFF MUST PRESERVE GOVERNANCE AUTHORITY\n\nThe minimum safe handoff must contain enough information to\nreconstruct: 1. what is required; 2. what has passed; 3. what remains;\n4. what is blocked; 5. what comes next; 6. why it comes next; 7. what\ncannot yet be done.\n\nA checkpoint that contains the current workbook but not the information\nnecessary to determine remaining mandatory requirements is unsafe.\n\n36. NO RELIANCE ON CHAT MEMORY FOR REQUIREMENT COMPLETENESS\n\nAt every major transition assume: The next AI chat remembers nothing\ntrustworthy about the project’s mandatory workflow.\n\nTherefore preserve the complete active governing logic in artifacts.\n\nConversational recollection may assist orientation.\n\nIt must not determine protocol compliance.\n\n37. CROSS-VALIDATION OF NEXT STEP\n\nBefore publishing a NEXT_STEP file or starter prompt, derive the next\noperation twice:\n\nMethod A: From the canonical requirement register and dependency graph.\n\nMethod B: From the project state and canonical state machine.\n\nThe two answers must agree.\n\nIf they do not: NEXT-STEP VALIDATION = FAIL\n\nDo not create a handoff that asserts a next step until reconciled.\n\n38. REQUIREMENT COVERAGE BEFORE AND AFTER EVERY MAJOR PHASE\n\nFor every major phase record:\n\nBEFORE PHASE: Mandatory requirements PASS: Mandatory requirements\nincomplete: Next permitted state:\n\nAFTER PHASE: Mandatory requirements PASS: Mandatory requirements\nincomplete: Next permitted state:\n\nThis makes disappearing requirements detectable.\n\n39. INDEPENDENT GLOBAL AUDIT BEFORE IRREVERSIBLE ACTIONS\n\nBefore an irreversible or difficult-to-reverse operation, perform an\nindependent protocol audit.\n\nExamples: - deleting/superseding source artifacts; - migration; - final\naggregation; - publication; - deployment; - release; - archive\ncompaction; - declaring research closed.\n\nThe audit should not merely reuse the local stage validator’s\nconclusion.\n\n40. MASTER PROTOCOL MUST BE RE-CONSULTED AT CONTROL POINTS\n\nThe full governing protocol must be re-consulted: - when establishing\nthe project; - when generating the requirement register; - after any\nprotocol amendment; - before major phase transitions; - before new-chat\nhandoff; - when rebuilding the state machine; - before final\nexport/release; - before closure; - whenever an inconsistency is\ndetected.\n\n41. APPROVED AMENDMENT SYSTEM\n\nChanges to governing requirements must use explicit amendments.\n\nRecommended file: APPROVED_PROTOCOL_AMENDMENTS.md\n\nEach amendment must contain: - Amendment_ID - Date - Original\nrequirement - Revised requirement - Reason - Impact - Dependencies\naffected - State-machine changes - Validator changes - Migration\nrequired - Approval status\n\nAfter approval, update: 1. governing protocol if appropriate; 2.\nrequirement register; 3. dependency graph; 4. state machine; 5.\nvalidators; 6. coverage matrix; 7. starter prompt templates; 8. handoff\ntemplates.\n\nThe amendment is not operationally complete until all affected control\nartifacts have been synchronized.\n\n42. GOVERNANCE SYNCHRONIZATION GATE\n\nAfter any protocol change, run a GOVERNANCE SYNCHRONIZATION GATE.\n\nCheck: PROTOCOL REQUIREMENT REGISTER STATE MACHINE DEPENDENCY GRAPH\nVALIDATORS PROMPTS PROJECT STATE HANDOFF TEMPLATE\n\nAll must agree.\n\nUntil then: PROJECT STATUS = GOVERNANCE UPDATE PENDING\n\nAffected production should not continue.\n\n43. REQUIRED VALIDATOR SEPARATION\n\nFor complex projects, use at least these conceptual validation layers:\n\nLAYER 1 — ARTIFACT INTEGRITY LAYER 2 — LOCAL CONTENT / STAGE QA LAYER 3\n— REQUIREMENT COVERAGE LAYER 4 — GLOBAL PROTOCOL COMPLIANCE LAYER 5 —\nRELEASE / CLOSURE ELIGIBILITY\n\nThese may be implemented in one program if appropriate, but the outputs\nmust remain logically distinct.\n\nDo not collapse them into one ambiguous PASS.\n\n44. PASS MUST BE QUALIFIED\n\nEvery PASS declaration should identify what passed.\n\nExamples: STAGE 5 LOCAL QA: PASS PROTOCOL COVERAGE: PASS GLOBAL PROTOCOL\nCOMPLIANCE: PASS RELEASE ELIGIBILITY: FAIL\n\nAvoid an unqualified PASS when multiple governance layers exist.\n\n45. PREVENT LOCAL COMPLETION FROM BECOMING GLOBAL COMPLETION\n\nThe project must distinguish: TASK COMPLETE PHASE COMPLETE MODULE\nCOMPLETE LOCAL WORKFLOW COMPLETE MANDATORY PROTOCOL COMPLETE PROJECT\nCOMPLETE\n\nThese statuses are not interchangeable.\n\n46. COMPLETENESS PROOF\n\nFor substantial projects, project closure should produce an explicit\ncompleteness proof or report demonstrating: - every mandatory\nrequirement ID; - final status; - evidence artifact; - validating\ngate; - amendment/waiver where applicable.\n\nRecommended filename: FINAL_PROTOCOL_COMPLETENESS_REPORT.md\n\n47. ADVERSARIAL OMISSION TEST\n\nBefore finalizing a major workflow, handoff, or release, ask:\n\n“Assume a future operator follows only the operational files we are\ngiving them and never reads our prior conversation. Which mandatory\nrequirement could they accidentally skip?”\n\nThen inspect the architecture specifically for that possibility.\n\nAlso ask:\n\n“Could a logically consistent but incomplete local workflow reach the\nfinal state?”\n\nIf yes, the architecture fails.\n\n48. NEGATIVE-PATH TESTING\n\nDo not test only valid progression.\n\nTest prohibited progression.\n\nExamples:\n\nCan P08 begin if P07B is NOT_STARTED? EXPECTED: NO\n\nCan release begin if ontology analysis is incomplete? EXPECTED: NO\n\nCan closure occur if one mandatory requirement is BLOCKED? EXPECTED: NO\n\nCan a starter prompt direct an operator around the state machine?\nEXPECTED: NO\n\nThese tests should form part of global validator QA.\n\n49. SIMULATED MISSING-STAGE TEST\n\nFor complex state machines, deliberately simulate at least one missing\nmandatory predecessor.\n\nThe global validator should fail.\n\nIf the validator still permits downstream progression, the validator\nitself fails QA.\n\n50. SIMULATED DERIVATIVE-PROMPT CONFLICT TEST\n\nCreate a test condition in which a local starter prompt proposes a\ndownstream stage that is not globally permitted.\n\nExpected result:\n\nLOCAL PROMPT CONFLICT DETECTED GLOBAL PROTOCOL TAKES PRECEDENCE\nEXECUTION BLOCKED\n\nIf production can continue despite the conflict, the safeguard is\ninadequate.\n\n51. COVERAGE-REGRESSION TEST\n\nEvery major protocol or workflow revision must verify:\n\nMANDATORY_REQUIREMENT_COUNT_NEW >= MANDATORY_REQUIREMENT_COUNT_PREVIOUS\n\nunless approved amendments intentionally removed requirements.\n\nMore importantly, compare requirement IDs and meanings, not only counts.\n\n52. SEMANTIC REQUIREMENT FINGERPRINT\n\nWhere appropriate, maintain a canonical representation or fingerprint of\ngoverning requirements.\n\nThis may include: - stable requirement IDs; - normalized descriptions; -\ngoverning section references; - hash of the requirement register.\n\nIf the requirement register changes unexpectedly, require explicit\nreview.\n\nA hash alone does not establish semantic correctness, but it helps\ndetect uncontrolled change.\n\n53. NEW-PROJECT PLANNING DELIVERABLE ADDITIONS\n\nEvery substantial new project created under the Universal New Project\nMaster Prompt must now include, where appropriate:\n\nPROTOCOL_REQUIREMENTS. PROTOCOL_COVERAGE_MATRIX.\nCANONICAL_WORKFLOW_STATE_MACHINE. DEPENDENCY_GRAPH.\nGLOBAL_PROTOCOL_COMPLIANCE_PROTOCOL.md GLOBAL_PROTOCOL_VALIDATOR.\nPROTOCOL_SEMANTIC_AUDIT_CHECKLIST.md APPROVED_PROTOCOL_AMENDMENTS.\n\nThese are not optional decorative documentation.\n\nThey are active project-control artifacts.\n\n54. ARTIFACT MANIFEST AUTHORITY FIELD\n\nThe Artifact Manifest must include fields such as:\n\nArtifact Purpose Authority_Level Governing_or_Derivative\nMay_Modify_Master_Workflow Required_for_Global_Compliance\nPreservation_Class Current_Status Supersedes Superseded_By\n\nFor most starter prompts:\n\nGoverning_or_Derivative = DERIVATIVE May_Modify_Master_Workflow = NO\n\n55. PROJECT STATE ADDITIONS\n\nThe machine-readable project-state manifest should additionally contain:\n\ngoverning_protocol: protocol_version: approved_amendments:\nprotocol_requirement_register: mandatory_requirement_count:\nmandatory_requirement_pass_count:\nmandatory_requirement_incomplete_count: canonical_state_machine:\nglobal_protocol_validator: last_protocol_semantic_audit:\nlast_protocol_semantic_audit_result: current_permitted_operations:\nnext_permitted_operation: starter_prompt_proposed_operation:\nnext_step_alignment: release_eligible: closure_eligible:\n\n56. HANDOFF MANIFEST ADDITIONS\n\nEvery major handoff manifest should explicitly identify:\n\nGOVERNING PROTOCOL APPROVED AMENDMENTS CANONICAL REQUIREMENT REGISTER\nCANONICAL STATE MACHINE CURRENT COVERAGE MATRIX GLOBAL VALIDATOR LATEST\nGLOBAL VALIDATOR RESULT CURRENT PROJECT STATE NEXT-STEP VALIDATION\nRESULT\n\nIf any critical one is absent in a project that requires it: HANDOFF =\nINCOMPLETE\n\n57. STARTER BUNDLE QA ADDITIONS\n\nThe starter-bundle audit must now ask:\n\nDoes the governing protocol exist? Does the requirement register exist?\nWas the requirement register audited against the full protocol? Does the\nstate machine represent every mandatory operation? Does the dependency\ngraph encode blocking predecessors? Does the global validator exist? Has\nnegative-path validator testing passed? Does the starter prompt\nexplicitly declare subordination? Can a local prompt redefine the next\nstage? Does the coverage matrix expose incomplete requirements?\n\nThe correct answer to: Can a local prompt redefine the next stage?\n\nmust be: NO\n\n58. END-OF-STEP REPORTING ADDITIONS\n\nEvery major governed step must additionally report:\n\nGLOBAL PROTOCOL COMPLIANCE\n\n-   Governing protocol version:\n-   Mandatory requirements total:\n-   Mandatory requirements PASS:\n-   Mandatory requirements incomplete:\n-   Local stage QA:\n-   Global protocol QA:\n-   Current state valid:\n-   Next permitted operation:\n-   Proposed next operation:\n-   Alignment:\n-   Release eligible:\n-   Closure eligible:\n\nIf local QA passes but global QA fails, state explicitly:\n\nLOCAL WORK PASSED, BUT PROJECT PROGRESSION IS BLOCKED.\n\n59. PRESERVATION RULE FOR GOVERNANCE ARTIFACTS\n\nThe following are normally PERMANENT ESSENTIAL or ESSENTIAL UNTIL\nSUPERSEDED: - frozen governing protocol; - approved amendments; -\ncanonical requirement register; - state-machine definition; - global\nvalidation specification; - final protocol-completeness report.\n\nDo not classify these as disposable simply because derivative prompts\nreproduce some of their content.\n\n60. DO-NOT-REPEAT-ERRORS ENTRY\n\nIf a workflow omission is ever discovered, record it in the project\nKNOWN_PROBLEMS / DO_NOT_REPEAT_ERRORS file.\n\nInclude:\n\nFAILURE CLASS: Protocol requirement omitted from active workflow\n\nROOT CAUSE: Derivative operational artifact narrowed governing workflow\n\nCONTROL FAILURE: Global requirement-completeness validation absent or\nineffective\n\nPREVENTION: Canonical requirement register + state machine + global\nvalidator + semantic handoff audit + starter-prompt subordination\n\nFuture project operators must review these lessons.\n\n61. PROJECT-WIDE CORRECTION RULE\n\nIf a control failure reveals that one completed module skipped mandatory\nprotocol requirements, do not assume the defect is isolated to that\nmodule.\n\nFirst determine whether the same flawed control architecture affected: -\nearlier completed modules; - currently active modules; - pending\nmodules; - handoff packages; - starter prompts; - validators; - release\noutputs.\n\nPerform a project-wide impact assessment.\n\nCorrect the control architecture before continuing routine production.\n\nThen determine which completed outputs require repair or revalidation.\n\n62. CONTROL-ARCHITECTURE-FIRST REPAIR\n\nWhen an omission occurs because the governance architecture permitted\nskipping:\n\nDo not merely repair the missing content.\n\nUse this order:\n\n1.  STOP affected downstream progression.\n\n2.  Identify the governance failure.\n\n3.  Correct the governing control architecture.\n\n4.  Update requirement register.\n\n5.  Update state machine.\n\n6.  Update validators.\n\n7.  Update prompts.\n\n8.  Re-audit active state.\n\n9.  Determine affected completed work.\n\n10. Repair/revalidate affected work.\n\n11. Resume normal production only after global PASS.\n\n12. ACTIVE PROTOCOL ENFORCEMENT PRINCIPLE\n\nThe project must embody this principle:\n\nRequirements must not merely be preserved. They must be operationally\nenforced.\n\nIt is insufficient that: - the protocol exists; - the protocol is\narchived; - the protocol appears in the handoff; - checksums match; -\nall files are internally consistent.\n\nThe project succeeds only if the active operational machinery forces\ncompliance with the governing requirements.\n\n64. DOCUMENTATION VERSUS EXECUTABLE GOVERNANCE\n\nAlways distinguish DOCUMENTED GOVERNANCE from EXECUTABLE GOVERNANCE.\n\nDocumented governance tells the operator what should happen.\n\nExecutable governance makes invalid progression fail.\n\nFor substantial projects, design for both.\n\n65. REQUIRED GLOBAL SAFETY INVARIANT\n\nEvery substantial governed project should preserve this invariant:\n\nIt must be impossible for the project to reach a release, deployment,\nfinal-export, or closure state while any blocking mandatory protocol\nrequirement remains incomplete, except through an explicit approved\namendment or waiver authorized by the governing protocol.\n\nAll state-machine, validator, handoff, and release architecture should\nbe designed around this invariant.\n\n66. FINAL PROTOCOL-COMPLIANCE QUESTIONS\n\nBefore every major transition, answer:\n\n1.  What is the highest-authority governing protocol?\n2.  What amendments are active?\n3.  How many mandatory requirements currently exist?\n4.  Does the active requirement register represent all of them?\n5.  Which remain incomplete?\n6.  What operation is globally permitted next?\n7.  Does the local starter prompt agree?\n8.  Are all blocking predecessors PASS?\n9.  Has any local artifact weakened or shortened the governing workflow?\n10. Has a semantic protocol audit passed?\n11. Would a fresh operator following only current operational files\n    still execute every mandatory requirement?\n12. Could release or closure occur while anything mandatory remains\n    incomplete?\n\nIf Question 12 is YES: GLOBAL CONTROL ARCHITECTURE = FAIL\n\nCorrect it before continuing.\n\n67. HARD STOP RULE\n\nThe following conditions require an immediate governance STOP:\n\nGoverning protocol cannot be identified. Canonical requirement register\nmissing. Requirement register does not reconcile with protocol. State\nmachine omits a mandatory requirement. Starter prompt conflicts with\ngoverning workflow. Mandatory predecessor incomplete. Global validator\nmissing where required. Global validator permits illegal progression.\nProtocol semantic audit fails. Unexplained requirement disappearance\ndetected. Release proposed with incomplete mandatory requirements.\nClosure proposed with incomplete mandatory requirements.\n\nDo not solve these by merely issuing another local prompt.\n\nRepair the governing control system.\n\n68. UNIVERSAL RULE TO INSERT INTO EVERY DERIVATIVE PROMPT\n\nEvery material derivative project prompt should contain this exact\nprinciple, adapted only where necessary:\n\nGOVERNANCE SUBORDINATION AND COMPLETENESS RULE\n\nThis prompt is an operational derivative, not the governing authority.\n\nThe frozen governing protocol, approved amendments, canonical\nrequirement register, and canonical project state machine remain\nauthoritative.\n\nThis prompt may specify the immediate permitted operation but may not\nomit, reorder, waive, reinterpret, weaken, or supersede any mandatory\ngoverning requirement.\n\nBefore execution, independently validate this proposed operation against\nthe complete canonical requirement register and current global project\nstate.\n\nLocal-stage PASS does not establish global protocol compliance.\n\nIf this prompt, the local workflow, a validator, a checkpoint, or any\nconvenience instruction conflicts with the governing protocol or permits\nprogression while a blocking mandatory requirement remains incomplete,\nSTOP. Treat the higher-authority governance system as controlling and\nrepair the discrepancy before continuing.\n\n69. UNIVERSAL RULE TO INSERT INTO EVERY GLOBAL VALIDATOR\n\nEvery global validator must enforce this principle:\n\nA downstream state is permitted only when every mandatory blocking\npredecessor defined by the complete canonical protocol requirement\nsystem is explicitly satisfied. Immediate-predecessor PASS alone is\ninsufficient.\n\n70. UNIVERSAL RULE TO INSERT INTO EVERY HANDOFF\n\nEvery major handoff must state:\n\nThis handoff has two independent integrity dimensions: artifact\nintegrity and protocol-semantic completeness. File presence, checksums,\nmanifests, and internal consistency do not prove that the active\nworkflow remains complete. Before production resumes, independently\nreconstruct and validate the mandatory workflow against the governing\nprotocol, requirement register, state machine, approved amendments, and\ncurrent project state.\n\n71. UNIVERSAL RULE TO INSERT INTO PROJECT CLOSURE\n\nBefore calling any substantial project complete:\n\nLOCAL FINAL QA = PASS ARTIFACT INTEGRITY = PASS PROTOCOL REQUIREMENT\nCOVERAGE = PASS GLOBAL PROTOCOL COMPLIANCE = PASS RELEASE QA = PASS\nFINAL COMPLETENESS REPORT = PASS\n\nNo subset of these may silently substitute for the whole.\n\n72. FINAL CONTROL PHILOSOPHY\n\nThe project architecture must be designed so that:\n\nThe complete governing workflow cannot gradually disappear through\nsummarization, local optimization, shortened starter prompts, checkpoint\ncompression, validator scope limitations, or transfer to a new chat.\n\nThe control system must preserve not merely the governing documents but\nthe effective enforceability of every mandatory requirement.\n\nThe project should therefore continually maintain alignment among:\n\nGOVERNING PROTOCOL ↓ APPROVED AMENDMENTS ↓ CANONICAL REQUIREMENT\nREGISTER ↓ DEPENDENCY GRAPH ↓ CANONICAL STATE MACHINE ↓ GLOBAL VALIDATOR\n↓ CURRENT PROJECT STATE ↓ DERIVATIVE PROMPTS ↓ LOCAL EXECUTION\n\nInformation may flow downward.\n\nAuthority may not silently flow upward.\n\nA derivative artifact may become more specific.\n\nIt may never become more governing than its source.\n\nThat rule is permanent.\n\nINTEGRATION REQUIREMENTS FOR THE UNIVERSAL MASTER PROMPT\n\nIn addition to the safeguards above, make these four changes to the\nUniversal New Project Master Prompt itself:\n\n1.  SINGLE SOURCE OF TRUTH Explicitly distinguish authoritative project\n    content from the authoritative governance system. A workbook may be\n    authoritative for data while the frozen protocol and requirement\n    register remain authoritative for what operations must be performed.\n\n2.  QUALITY ASSURANCE Every major PASS is two-dimensional: LOCAL QA\n    PASS + GLOBAL PROTOCOL COMPLIANCE PASS. A local validator with zero\n    errors must never authorize downstream progression on its own.\n\n3.  HANDOFF PROTOCOL Every handoff must require both:\n\n-   Artifact Integrity Audit\n-   Protocol Semantic Completeness Audit\n\nThe semantic audit must independently reconstruct the mandatory workflow\ninstead of merely trusting the active starter prompt.\n\n4.  MINIMUM SAFE PROJECT SET For any sufficiently complex project,\n    include:\n\n-   PROJECT_PROTOCOL_REQUIREMENTS.json\n-   PROTOCOL_COVERAGE_MATRIX.csv\n-   CANONICAL_WORKFLOW_STATE_MACHINE.json\n-   DEPENDENCY_GRAPH.json\n-   APPROVED_PROTOCOL_AMENDMENTS.md\n-   GLOBAL_PROTOCOL_COMPLIANCE_PROTOCOL.md\n-   Global validator or equivalent checklist\n-   PROJECT_STATE.yaml\n\nKEY PROJECT-WIDE INVARIANT\n\nNo release, export, deployment, or closure can become reachable while\nany blocking mandatory governing requirement remains incomplete.\n\nThe master protocol must function as an executable control system rather\nthan merely as documentation stored in the project folder.\n",
  "summary": "MANDATORY PROTOCOL COMPLIANCE AND REQUIREMENT-COVERAGE CONTROL LAYER This entire section is mandatory for every project governed by this master prompt. Its purpose is to prevent a recurring class of project failure: A complete governing protocol exists, but a derived prompt...",
  "date_modified": "2026-08-19",
  "publisher": {
    "name": "AI Bible Commentary",
    "url": "https://ai-bible-commentary.com/"
  }
}