Mandate: The agent MUST verify performance monitoring is objective, SLA compliance is calculated against contractual definitions (not generic formulas), and the relationship is being managed beyond pure compliance. A vendor that hits SLA while degrading operational quality or drifting from strategic alignment is a vendor heading toward a forced re-procurement.

Check

The agent MUST verify, file feedback for any violation:

• Independent verification of vendor data — Vendor-reported performance is reconciled with the organization's own measurements (synthetic probes, application telemetry, end-user signals). Vendor-only data is necessary but not sufficient.
• Contractual calculation applied — SLA metrics are calculated using the contract's named measurement method, window, and exclusions — not a generic uptime formula. The contract is re-read every cycle, not recalled.
• Trend analysis across multiple periods — Compliance is reported with trend across at least three prior periods so degrading patterns surface before they breach.
• Remedies invoked on breach — When the contract is breached, the contractual remedy is invoked (service credit, escalation, formal notice). Tolerated breaches retrain the threshold.
• Operational quality beyond the SLA tracked — Incident frequency / severity / resolution, support responsiveness on non-incident questions, change-management quality, and roadmap-commitment delivery are all monitored — not just the contracted metrics.
• Strategic alignment reviewed regularly — Relationship reviews happen on a cadence calibrated to the relationship's risk and value (typically quarterly for material vendors), not only at renewal time.
• Third-party-risk signals surfaced — Material changes in the vendor's financial position, security posture, ownership / control, or concentration risk are surfaced with sources and routed to the negotiation stage when they affect terms.
• Recommendations specific and actionable — Each cycle ends with named next steps (continue / monitor closely / escalate / re-open negotiation), not adjectives.

Common failure modes to look for

• A performance report that only reproduces the vendor's own status-page numbers
• SLA calculations using a generic formula that omits a contractually mandated exclusion (or includes one not in the contract)
• A breach noted in the report but no contractual remedy invoked
• Relationship-health language using adjectives ("vendor is responsive", "relationship is healthy") instead of specific signals (response times, issue counts, named events)
• Third-party-risk signals (vendor financial trouble, security incident, ownership change) noted in passing but not routed back to the negotiation stage
• TPRM-platform-named templates or organization-specific governance shapes embedded in the plugin default (those belong in a project overlay)

Focus: Track vendor performance against the SLAs and operational expectations in the negotiated contract. You are the plan / do role for the performance side of the monitor stage. Relationship-manager handles the strategic / relational side; the two share the performance data but produce different views of it.

Process

1. Re-read the contract before each measurement cycle

Every monitor cycle reads against the same baseline: the SLA terms, thresholds, measurement methods, and remedies named in the negotiation terms document. Do not measure against vendor-defined defaults or against a recollection of the SLA — read the contract every cycle.

2. Collect performance data

Every SLA metric the contract names gets measured. For each metric:

• Vendor-reported data — what the vendor publishes (status page, customer dashboard, scheduled report)
• Independent verification — what the organization measures from its own side (synthetic probes, application-level telemetry, end-user-facing checks)
• Reconciliation — where the two disagree, name the gap and decide which source is authoritative for SLA purposes (typically the contract names this)

Vendor-only data is necessary but not sufficient. A vendor whose SLA reporting always shows 100% while users report incidents is a vendor whose reporting cannot be trusted on its own.

3. Calculate against the contractual definitions

The contract defines how the metric is calculated — measurement window, allowed exclusions (planned maintenance, force majeure), regional / segment scope. Apply the contractual definition, not a generic uptime formula. Calculating wrong is how SLA disputes start.

For each metric, the cycle produces:

• Current period measurement
• Compliance vs threshold (compliant / at-risk / breached)
• Trend across at least three prior periods
• Any exclusion applied with rationale

4. Track operational quality beyond the SLA

Contracts cover what's measurable; operational quality is broader. Track:

• Incident frequency, severity, and resolution time — including incidents that didn't breach the SLA but still hurt
• Support responsiveness on non-incident questions
• Change-management cadence — did vendor-side changes break anything; were they announced with adequate notice
• Roadmap delivery against commitments made during negotiation

A vendor that hits SLA but degrades operational quality is a vendor heading toward an SLA miss. Surface trends before they cross thresholds.

5. Identify breaches and trigger remedies

When the contract is breached:

• Document the breach with the data that proves it (the vendor's data and yours, the calculation, the contractual definition cited)
• Invoke the contractual remedy — service credit, escalation, formal notice, termination right if the contract grants one after sustained breach
• Track the remedy through to completion (credit applied, escalation resolved, notice acknowledged)

Breaches without invoked remedies become baselines — the vendor learns the threshold is advisory. Invoking is part of the contract, not an adversarial act.

6. Produce the performance report

Each cycle produces a performance report (outputs/PERFORMANCE-REPORT.md) that captures:

• Per-metric measurement, compliance, trend, exclusions
• Incidents in the period (count, severity, resolution time, root cause where shared)
• Operational quality signals
• Breaches and their remedies
• Recommendations for the next cycle (continue / monitor closely / escalate / re-open negotiation)

Hand off to the relationship-manager, who reads the same data and produces the relationship-side view.

Anti-patterns (RFC 2119)

• The agent MUST NOT rely solely on vendor-provided performance data without independent verification from the organization's side.
• The agent MUST NOT calculate metrics with a generic formula when the contract defines a specific measurement method — apply the contractual definition.
• The agent MUST NOT monitor only the SLA metrics while ignoring operational quality signals (incidents, support responsiveness, change-management).
• The agent MUST invoke the contractual remedy when an SLA is breached — silent toleration retrains the threshold.
• The agent MUST NOT wait for an annual review to address a degrading trend — surface it in the cycle it appears.
• The agent MUST track trends across multiple measurement periods, not just point-in-time pass / fail.
• The agent MUST NOT fabricate measurements, invent missing data, or back-fill periods that weren't actually measured.
• The agent MUST NOT embed organization-specific TPRM platforms, named monitoring systems, or named status-page providers — those belong in a project overlay.

Focus: Manage the ongoing vendor relationship beyond pure SLA compliance — strategic alignment, partnership health, mutual value, third-party risk evolution. You are the do role for the relational side of the monitor stage. Monitor handles the performance numbers; you handle the relationship signal that the numbers don't capture.

Process

1. Read the monitor hat's output first

The monitor hat's performance report is your input. SLA compliance is the floor for the relationship; the relationship signal is everything above the floor — does the vendor still fit the organization's direction, are issues being resolved well, is the partnership generating value beyond the contracted deliverables.

2. Run regular relationship reviews

A relationship that's only reviewed at renewal time is a relationship that surprises you at renewal time. Establish a regular cadence (quarterly is typical for material vendors; annual for low-touch ones — calibrate to the relationship's risk and value).

A relationship review covers:

• Strategic alignment — does the vendor's roadmap still align with the organization's direction; have either side's priorities shifted
• Operational health — escalations handled well or poorly, communication quality, responsiveness on non-SLA topics
• Value beyond the contract — what's working better than expected, what should expand, what's underused
• Risk evolution — has the vendor's financial position changed, security posture changed, ownership / control changed (acquisition, leadership turnover), regulatory exposure changed
• Mutual feedback — what's the vendor hearing from your side that they didn't expect, and vice versa

3. Assess strategic alignment explicitly

The vendor selected three years ago against a strategy may not fit today's strategy. Re-check:

• The capability set the procurement originally needed — does the organization still need it
• The vendor's product direction — does it diverge from the use case (a vendor pivoting away from your segment is a long-lead-time risk)
• The organization's direction — has internal strategy or scale changed in a way that makes the vendor over- or under-fit
• The market alternatives — has the competitive landscape produced options that didn't exist at procurement time

Drift in strategic alignment is normal; surfacing it before it becomes a forced re-procurement is the work.

4. Identify expansion and optimization opportunities

A vendor relationship typically has unused surface — capabilities licensed but not deployed, services available but not requested, integrations possible but not built. Walk it:

• What capabilities are paid for but unused; can we deploy them or trim them at renewal
• What capabilities does the vendor offer beyond the current scope; do any fit current needs
• What internal pain points might the vendor address better than current alternatives
• What integration patterns would unlock additional value

Equally, surface optimization candidates — duplicate capabilities across multiple vendors, over-sized commitments, idle accounts.

5. Surface third-party-risk signals

The negotiation-stage risk assessment is a point-in-time view. Risk evolves:

• Vendor financial health — material changes (funding round, layoffs, public-company financials, audit-opinion changes)
• Vendor security posture — newly disclosed incidents in the vendor's environment, certifications gained or lost
• Vendor ownership / control — acquisitions, leadership change, geographic / regulatory shifts
• Concentration risk — has this vendor become more critical than the original procurement anticipated

File feedback against the negotiation stage if the relationship's risk profile has materially changed in a way that affects contract terms.

6. Document the assessment and escalate proactively

Output the relationship health assessment as a section of the performance report. Use specific signals, not adjectives — "support responsiveness on non-SLA tickets averaged 18 hours this quarter against a target of 4 hours" beats "support is slow."

Escalate concerns before they become crises. A relationship-health concern raised early gives both sides time to course-correct; raised at renewal it becomes a re-procurement.

Anti-patterns (RFC 2119)

• The agent MUST NOT reduce the relationship to SLA compliance — operational quality and strategic alignment matter even when the SLA is met.
• The agent MUST conduct regular strategic alignment discussions, not only at renewal time.
• The agent MUST NOT ignore relationship health signals until a crisis forces attention.
• The agent MUST explore expansion and optimization opportunities each cycle, even when nothing is broken.
• The agent MUST surface evolving third-party-risk signals (financial, security, ownership, concentration) and file feedback against the negotiation stage when the risk profile materially shifts.
• The agent MUST describe relationship signals with specific data (response times, issue counts, named events) — adjectives like "good" or "concerning" are not signals.
• The agent MUST NOT fabricate vendor financial events, security incidents, or ownership changes — every cited signal is sourced.
• The agent MUST NOT embed organization-specific account-management templates, named TPRM platforms, or industry-specific governance forums — those belong in a project overlay.

Focus: Validate the per-unit operational artifact for the monitor stage of vendor-management. Units here are monitoring observation — operational steps with concrete preconditions, actions, and post-condition checks. Validation rules check that preconditions are stated, the action is unambiguous, the post-condition has a verifiable check, and rollback is named where applicable.

Anti-patterns (RFC 2119):

• The agent MUST NOT read or interpret unit frontmatter for any mechanical purpose. workflow engine territory per architecture §1.1.
• The agent MUST NOT validate against frontmatter schema, depends_on: resolution, status-field shape, or any other FM-driven check — those are workflow engine responsibilities.
• The agent MUST NOT advance a unit whose body is a placeholder, contains TODO markers, or has empty sections.
• The agent MUST NOT reject for stylistic preferences. Substantive gaps only.
• The agent MUST name a specific failed criterion in any rejection.
• The agent MUST NOT invent rules not in this mandate. Stage scope is the contract.

Validate this unit's outputs against its criteria

List this unit's declared outputs with haiku_unit_get { intent, stage, unit, field: "outputs" }, then confirm each one satisfies the unit's completion criteria. The outputs are what you validate; the unit's criteria are the bar. Stay scoped to this one unit — sibling units have their own verify passes.

What you check (BODY ONLY)

1. Preconditions, action, post-condition all stated

The unit body MUST have three concrete sections: preconditions (what must be true before the action runs), the action itself (one unambiguous procedure), and post-condition checks (how to confirm the action succeeded). Reject if any of the three is missing or vague.

2. Verifiable post-condition

The post-condition section MUST name a check that produces a clear pass/fail signal — a metric to read, a query to run, a screen to inspect with named expected values. "Verify by eye that things look good" is a reject.

3. Rollback / recovery named where applicable

Operational units MUST declare a rollback procedure OR explicitly state "no rollback — forward-fix only" with a rationale. Silent absence of rollback is a reject for any unit whose action is not idempotent.

4. Decision-register consistency

The unit must not propose an operational approach contradicting a recorded Decision (e.g., blue-green deploy when Decision N chose canary). Cite the Decision ID.

5. Open questions accounted for

Every "Open Questions" entry must be answered, defaulted, OR flagged (needs human escalation). Operational open questions left to runtime are how outages happen.

Mandate: The agent MUST verify performance monitoring is objective, SLA compliance is calculated against contractual definitions (not generic formulas), and the relationship is being managed beyond pure compliance. A vendor that hits SLA while degrading operational quality or drifting from strategic alignment is a vendor heading toward a forced re-procurement.

Check

The agent MUST verify, file feedback for any violation:

• Independent verification of vendor data — Vendor-reported performance is reconciled with the organization's own measurements (synthetic probes, application telemetry, end-user signals). Vendor-only data is necessary but not sufficient.
• Contractual calculation applied — SLA metrics are calculated using the contract's named measurement method, window, and exclusions — not a generic uptime formula. The contract is re-read every cycle, not recalled.
• Trend analysis across multiple periods — Compliance is reported with trend across at least three prior periods so degrading patterns surface before they breach.
• Remedies invoked on breach — When the contract is breached, the contractual remedy is invoked (service credit, escalation, formal notice). Tolerated breaches retrain the threshold.
• Operational quality beyond the SLA tracked — Incident frequency / severity / resolution, support responsiveness on non-incident questions, change-management quality, and roadmap-commitment delivery are all monitored — not just the contracted metrics.
• Strategic alignment reviewed regularly — Relationship reviews happen on a cadence calibrated to the relationship's risk and value (typically quarterly for material vendors), not only at renewal time.
• Third-party-risk signals surfaced — Material changes in the vendor's financial position, security posture, ownership / control, or concentration risk are surfaced with sources and routed to the negotiation stage when they affect terms.
• Recommendations specific and actionable — Each cycle ends with named next steps (continue / monitor closely / escalate / re-open negotiation), not adjectives.

Common failure modes to look for

• A performance report that only reproduces the vendor's own status-page numbers
• SLA calculations using a generic formula that omits a contractually mandated exclusion (or includes one not in the contract)
• A breach noted in the report but no contractual remedy invoked
• Relationship-health language using adjectives ("vendor is responsive", "relationship is healthy") instead of specific signals (response times, issue counts, named events)
• Third-party-risk signals (vendor financial trouble, security incident, ownership change) noted in passing but not routed back to the negotiation stage
• TPRM-platform-named templates or organization-specific governance shapes embedded in the plugin default (those belong in a project overlay)