PM-301f · Module 2

Intermediate Output Specification

5 min read

Intermediate outputs are the handoffs between sub-tasks. They are not visible to the end user — they are contracts between steps. Treat them exactly like API contracts between services: specify the format, the required fields, the types, and what to return when the output is partial or unavailable.

# Intermediate Output: S2 → S3 Contract

S2 (Clause Extraction) MUST produce:
{
  "clauses": [
    {
      "clause_id": "string — format: [section].[paragraph], e.g. '4.2'",
      "text": "string — verbatim clause text",
      "section_title": "string — section heading under which this clause appears",
      "party_obligated": "string — 'vendor' | 'client' | 'both' | 'neither'",
      "clause_type": "string — 'payment' | 'liability' | 'IP' | 'termination' | 'SLA' | 'other'"
    }
  ],
  "extraction_coverage": "number — 0 to 1, fraction of document processed",
  "truncated": "boolean — true if document was too long and some clauses were not extracted"
}

S3 (Risk Scoring) REQUIRES:
- clauses array: must be non-empty
- Each clause must have clause_id, text, and clause_type
- party_obligated and section_title are optional but improve scoring accuracy

Partial output handling:
- If truncated is true: S3 must note in its output that scoring is based on partial extraction
- If clauses is empty: S3 must return { error: "No clauses provided — cannot score" } and halt
- If clause_type is missing from some clauses: S3 proceeds but notes reduced confidence

Do This

  • Specify intermediate output as a formal schema — field names, types, constraints
  • Define what partial output looks like and how the next step handles it
  • Include validation logic in each sub-prompt: "Verify these fields are present before proceeding"
  • Define what the receiving step does when required fields are absent

Avoid This

  • Pass intermediate output as unstructured text that the next step must parse
  • Leave partial output handling undefined — this is where silent failures begin
  • Use different field names for the same concept across different steps
  • "The output from step 2" as the complete specification for step 3's input