Serviceability Policy

1) Serviceability comes before commercial enthusiasm

A lead can be attractive and still be impossible to serve safely or reliably. Serviceability Decision Policy v1 asks a narrower question before scoring the opportunity: can the current product and operating model meet the declared Region, data, integration, quota, capacity, support and compliance constraints with evidence that exists now?

2) Turn requirements into hard constraints

Write every requirement as a testable field: required Region, service availability, data residency, connector dependency, forecast peak, quota headroom, tested capacity, support response, latency and compliance. A vague statement such as “engineering can probably handle it” is not evidence.

3) Region is an evidence dimension, not a preference

AWS Well-Architected notes that Region choice affects workload KPIs such as performance and cost. For this lesson, the Region requirement is therefore explicit. The AWS fact does not decide MAKNOW commercial eligibility; it only shows why Region cannot be hidden inside a generic architecture preference.

4) Availability and integration must exist now

A service or connector that is planned, private-preview only, unsupported in the required Region, or not evidenced is not present capability. If the dependency is decisive and evidence is missing, return HOLD; if it is explicitly unavailable with no bounded exception path, return UNSERVICEABLE.

5) Quota headroom must be compared with forecast peak

AWS documents quotas as account- and often Region-specific and recommends continual assessment. Record the quota scope and compare available headroom with the declared peak requirement. If the headroom is below the peak and no approved increase exists, the hard constraint fails.

6) Capacity evidence needs freshness

Quota permission is not the same as tested throughput. Record the most recent capacity/load evidence and its age. When decisive capacity evidence exceeds the declared freshness window, preserve STALE rather than treating an old successful test as current proof.

7) Support and compliance are service constraints

Support response windows, data residency and compliance commitments can block an otherwise attractive architecture. Do not hide them inside an aggregate score. A two-hour customer requirement is not satisfied by a four-hour current operating window unless a bounded and approved mitigation closes the gap.

8) Exceptions need owner, cost and expiry

A conditional exception is a temporary operating commitment, not a sentence saying “we will fix it later.” Record the accountable owner, incremental cost, expiry, evidence reference and exact constraint being mitigated. If owner or expiry is missing, the exception is not valid.

9) Use typed states instead of forced optimism

SERVICEABLE means hard constraints pass without an active exception. CONDITIONAL means all hard constraints can be met only through a current, owned, costed and time-bounded exception. UNSERVICEABLE means a hard constraint fails. HOLD, PARTIAL, DISPUTED, STALE and BLOCKED preserve different evidence failures instead of flattening them into “maybe yes.”

10) Baseline Serviceability Decision Policy

The worked baseline is serviceable because Region/service availability, residency, connector, quota, capacity, support and compliance all pass with current evidence. No exception is needed and its cost is therefore zero.

11) Wrong shortcut: quota below forecast peak

If required peak throughput is 100 units while Region/account quota headroom is only 80, the opportunity is not currently serviceable. Sales urgency and a high lead score cannot override the hard constraint. A future quota request is a remediation plan, not current proof.

12) Missing connector evidence and expired exceptions

Removing evidence for a required connector forces HOLD; inventing support is forbidden. If an exception for a partial dependency has expired while the underlying gap remains, the decision becomes UNSERVICEABLE until new authority/evidence is established.

13) Lab: eight fixtures, 64 assertions

The offline lab evaluates a clean baseline, quota failure, missing connector evidence, missing exception owner, expired exception, stale capacity evidence, an unrecomputed material change and the transfer scenario. Every fixture emits eight deterministic fields and requires no API key or live tenant.

14) Transfer: connector GA, tighter quota and shorter support window

Recompute from the changed evidence. The connector is now generally available, quota headroom is reduced but still above the declared peak, and the customer requires a two-hour response while current operations provide four hours. A named on-call mitigation costs 1,200 units per month and expires on a declared date, so the bounded state becomes CONDITIONAL, not automatically SERVICEABLE.

15) Delivery checklist

All hard constraints are explicit; Region/account scope is visible; availability and integration are current; quota is compared with forecast peak; capacity evidence freshness is checked; support/compliance are separate gates; every exception has owner/cost/expiry; typed non-success states are preserved; transfer is recomputed; and no external platform guidance is treated as MAKNOW commercial authority.