Contracts

Service agreements with their terms, values, covered sites, and renewal clocks - so expirations stop being surprises.

The contracts module exists for one recurring failure mode: the service agreement nobody re-tendered because nobody knew it was expiring. Every agreement gets a record with a clock on it.

Contract records

• Title, company, and category - the vendor holding the agreement, and what kind of service it is
• Term - start and end dates; the end date drives the expiring flag - plus an extendable flag for agreements with a renewal option
• Annual cost - for spend oversight
• Purchase order - the PO reference the agreement runs under
• Quality score - rate the vendor's delivery 1-10; this is where vendor performance history lives
• Covered sites and infrastructure networks - what the agreement serves
• Description and documents - the signed agreement, amendments, insurance certificates

Renewal tracking

The contracts list splits into All / Active / Expiring / Expired tabs. Expiring means the end date falls within the next 90 days - enough lead time to re-tender rather than rubber-stamp. Expired-but-still-operating agreements - the riskiest kind - sit on their own tab.

Contracts and the work loop

Work orders assigned to a vendor under contract build the delivery record: when renewal comes, "how many calls did they actually take last term, and how fast?" is a filter on work order history, not a guess.

Suggested lifecycle

1. On signing - create the record, attach the PDF, set term and cost, link sites.
2. During the term - assigned work orders accumulate; spot-check spend vs. cost; keep the quality score honest.
3. When it appears on the Expiring tab - pull the vendor's delivery history; decide renew / renegotiate / tender.
4. On expiry - create the successor agreement as its own record; the old one stays on the Expired tab as history.

Programmatic access

contracts:read / contracts:write on the REST API; contract and contract-site tools via MCP.