[00 / TECHNICAL BRIEF]

Built on the first-party Claude API, with no retrieval layer in the way.

This page is written for CTOs, VPs of Engineering and security reviewers. It describes how LaunchStruc LLC designed StrucPact around four properties of the Anthropic Claude API: long context, prompt caching, model tiers and schema-constrained tool use.

[01 / CONTEXT]

200K+ context ingestion without lossy chunking

Contracts are cross-referential documents. A fixed-size retrieval chunk cannot be trusted to carry them.

Why not retrieval-augmented chunks

A limitation-of-liability clause on page 28 is only meaningful alongside the definition of “Fees” on page 4, the carve-outs in Section 8.5 and the cap amount in Schedule C. Chunked retrieval returns the passages that look most similar to a query, not the ones a lawyer would read together. Missing a carve-out produces a confident and wrong redline.

What StrucPact does instead

The full agreement, plus attached schedules, exhibits and order forms, is placed in a single request. A typical 46-page MSA with exhibits is in the range of 60K tokens, which fits the 200K window with room for the playbook and structured output. Documents beyond the window are split on structural boundaries (article or schedule), never on token count, and a shared definitions block is repeated in each part.

[02 / CACHING]

Ephemeral prompt caching of the playbook

The playbook is the largest repeated input. It is also the part that never changes between two contracts from the same customer.

Cached prefix layout

The system prompt is ordered from most stable to least stable. Instructions first, then the customer risk playbook and fallback clause library marked with an ephemeral cache breakpoint, then the contract in the user turn. Anything before the breakpoint is eligible to be read from cache.

Cost and latency effect

Cached input tokens are billed at a fraction of the base input price, and a cache hit shortens time to first token because the prefix does not have to be processed again. In our workloads this yields up to 90% lower input cost and up to 75% lower time to first token on the cached portion. Actual savings depend on playbook size relative to contract size and on how often reviews arrive inside the cache window.

Invalidation rules

Editing a playbook rule changes the prefix, so the next request writes a new cache entry. Nothing is reused across customers: each playbook prefix is unique to one customer and one version. Usage fields such as cache_read_input_tokens are recorded per review so the saving is auditable.

[03 / ROUTING]

Tiered routing: Haiku triages, Sonnet drafts

Most clauses in a vendor agreement are compliant. Paying for a larger model to confirm that is waste.

Stage	Model	Work	Output
01 Extract	Claude Haiku	Agreement type, governing law, term, renewal and notice mechanics	extract_metadata
02 Classify	Claude Haiku	Label every clause and flag those that trigger a playbook rule	classify_clause
03 Draft	Claude Sonnet	Bilateral indemnification, liability cap interplay and redline drafting for flagged clauses only	record_redline
04 Verify	Deterministic code	Schema validation, rule-id check against the enabled playbook, text diff against the source	accepted / rejected

A clause escalates only when Haiku sets escalate to true. If Sonnet returns a rule identifier that is not in the customer's enabled playbook, or proposed text that does not differ from the original, the verifier rejects the finding and it never reaches the reviewer.

[04 / SCHEMA]

Structured tool use and schema enforcement

Each stage answers through a tool with a closed JSON schema, selected with a forced tool choice.

The playbook and fallback library are marked cacheable. The contract follows, uncached.

{
  "model": "claude-sonnet-5-5",
  "max_tokens": 4096,
  "system": [
    {
      "type": "text",
      "text": "You enforce the customer's vendor-contract playbook. Cite a rule id for every finding."
    },
    {
      "type": "text",
      "text": "<playbook>...rules PB-FIN-04, PB-LIA-02, PB-TRM-01, PB-DAT-07...</playbook>\n<fallback_clauses>...</fallback_clauses>",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "tools": [ { "name": "record_redline", "...": "see schema tab" } ],
  "tool_choice": { "type": "tool", "name": "record_redline" },
  "messages": [
    {
      "role": "user",
      "content": "<contract id=\"msa-0412\">...full agreement, schedules and exhibits...</contract>"
    }
  ]
}

[05 / NEXT]

Review the design with an engineer

We walk technical reviewers through prompt layout, cache behavior and failure handling on a live document.

Book an architecture review Security and trust