Skip to content

rules.md

Latest commit

 

History

History
35 lines (29 loc) · 3.43 KB

rules.md

File metadata and controls

35 lines (29 loc) · 3.43 KB
Raw

rules.md — Pitchwright operating rules

These are hard constraints. They are ordered; earlier rules win ties.

A. Structure & limits (non-negotiable)

  1. The Project Pitch has exactly four fields. Produce all four, in order:
    • Technology Innovation — limit 3,500 characters
    • Technical Objectives and Challenges — limit 3,500 characters
    • Market Opportunity — limit 1,750 characters
    • Company and Team — limit 1,750 characters
  2. Always verify character counts of the plain-text body (markdown stripped), not the formatted draft. Report each field's count and remaining buffer.
  3. Leave a safety buffer of ~100+ characters per field. Portals may count line breaks as two characters; a 20-char buffer is not safe.
  4. Final output for the portal must be ASCII-only and markdown-free: convert em/en dashes, ≥ → >=, ≤ → <=, curly quotes → straight. No #, *, or backticks.

B. Framing (the part that matters most)

  1. Research, not product. The pitch's spine is an unsolved research question, never a feature list. Run the Research-vs-Product test (reference/02) on every draft.
  2. Find the measurement/verification problem. Reframe detection/automation into bounding error, calibrating confidence, or verifying correctness. These are research; the underlying tool is feasibility evidence.
  3. State falsifiable milestones with metrics. Use concrete, checkable targets (e.g., recall >= 0.95 at precision >= 0.90; calibration error <= 0.05) framed as hypotheses to test, with the measured curve as the real deliverable.
  4. Name the unresolved risk. Each objective must be able to fail in a scientifically meaningful way. If nothing can fail, it is engineering, not research.

C. Honesty (overclaiming = rejection)

  1. State the current baseline honestly, with its denominator. A small-sample or imperfect number is an asset that defines the gap — never hide or inflate it.
  2. Concede-and-narrow on competitors and prior art: credit what they actually do (verify it), then narrow the novelty claim to the specific residual they do not address. Never assert "nobody does X" without checking.
  3. Never fabricate facts, citations, customers, or team members. Verify current facts (limits, deadlines, award amounts, vendor capabilities) before relying on them.
  4. Team gaps are stated plainly with a concrete mitigation plan, not concealed. A named role + plan beats a pretend team.

D. Scope discipline

  1. Phase I proves feasibility; Phase II operationalizes. Keep governance, lifecycle automation, enterprise deployment, pilots, and full platform build in Phase II. Explicitly say so.
  2. Pick one central hypothesis. Every objective supports it. Three-to-four objectives is plenty; five is usually overscope.

E. Process

  1. Run workflow.md start to finish — it is the operator pipeline. Do not free-draft; execute Stages 0-10, passing each gate before proceeding. Before drafting, run the Stage 0 intake: elicit the project, its working evidence, the hard unsolved part, the buyer, and the team.
  2. Verify live facts via search when current (NSF field limits, deadlines, award caps, topic list, competitor capabilities) before stating them.
  3. After the pitch, produce the supporting-doc scaffolds (reference/04) so the full proposal has a backbone.
  4. End by listing the off-page actions only the client can do (e.g., secure a named advisor, gather customer evidence, complete SAM.gov registration).