4. Request modes and evidence

SPEAR does not treat every request the same way. It reads the class of each request — GENERAL, IMPLEMENTATION, NORMATIVE or MIXED — and runs it on the path where its evidence can be kept: changes on the coding core behind its control plane, questions about a standard on the normative runtime, and changes that must satisfy a standard through both, judged on evidence the model cannot supply.

• 4.1. Implementation mode
  • 4.1.1. The coding core
  • 4.1.2. SpearHost — the execution boundary
  • 4.1.3. One repair after a failed project validation
  • 4.1.4. Example
• 4.2. Normative mode: authoritative standards
  • 4.2.1. Which documents are supported
  • 4.2.2. Ingesting a document
  • 4.2.3. Binding an authoritative source
  • 4.2.4. The normative tools
  • 4.2.5. Provision identity
  • 4.2.6. Normative force
  • 4.2.7. Why an implementation comment is not authority
  • 4.2.8. When SPEAR withholds an answer
  • 4.2.9. An example, end to end
  • 4.2.10. Questions and changes about both sides
• 4.3. Mixed mode
  • 4.3.1. When a request is MIXED
  • 4.3.2. The three passes
  • 4.3.3. The normative authority model
  • 4.3.4. One bounded repair
  • 4.3.5. The verdict
  • 4.3.6. Examples
• 4.4. Evidence and verdicts
  • 4.4.1. Implementation evidence
  • 4.4.2. Normative evidence
  • 4.4.3. Composite verdicts
  • 4.4.4. COMPLIANCE NOT DEMONSTRATED
  • 4.4.5. Evidence conflict
  • 4.4.6. Examples
• 4.5. Normative answer guards
  • 4.5.1. Three kinds of evidence
  • 4.5.2. What the guards check
  • 4.5.3. Why SPEAR withholds
  • 4.5.4. Why “incomplete” is a result
  • 4.5.5. Auditing a session
• 4.6. The bound-session change workflow
  • 4.6.1. Why the stages are separate
  • 4.6.2. INVESTIGATE
  • 4.6.3. PLAN
  • 4.6.4. EDIT
  • 4.6.5. TEST
  • 4.6.6. REVIEW