Dedicated Instance Pattern

1) Dedicated is a boundary decision, not a customer fork

A request for a “dedicated instance” does not automatically justify a separate codebase, release train, identity system, or operations team. Dedicated Instance Eligibility & Fleet Contract v1 first asks which resource planes must actually be dedicated and which product/control-plane capabilities can remain shared.

2) Start from a hard isolation reason

Write the reason in evidence: regulation, data residency, hard performance isolation, or another explicit constraint. “The customer prefers dedicated” is not enough. If the hard reason disappears, the existing footprint must be re-evaluated instead of being preserved by inertia.

3) Separate dedicated planes from the shared control plane

A tenant can have dedicated compute and data while identity, onboarding, release orchestration, observability standards, incident tooling, and product governance remain shared. This distinction is how a SaaS silo avoids becoming a managed one-off product.

4) External facts versus MAKNOW design

Azure Deployment Stamps and AWS SaaS isolation guidance establish useful patterns: a stamp may be single-tenant, silo resources can coexist with shared SaaS operations, and dedicated premium environments can stay on the same product version. They do not define MAKNOW eligibility thresholds or pricing rules.

5) Reserve capacity honestly

A dedicated footprint must reserve enough capacity for the declared peak. Compare reserved_capacity with peak_capacity_requirement under the same scope. Idle capacity still has recurring cost and fleet burden; it is not free simply because the customer is not using it.

6) Expose the unit-cost floor

The simplest floor in this lab is recurring reserved cost divided by projected useful units. It is not a billing formula. It is a guard against approving a dedicated footprint without seeing the economic consequence of unused reserved capacity.

7) Automation is a fleet gate

One dedicated tenant may look manageable. A fleet of dedicated tenants is different. Provisioning, upgrades, observability, backup, restore, drift checks, incident response and decommissioning need automation. A low automation score is a recurring operations liability, not a one-time setup issue.

8) Keep one product version

A dedicated resource plane should not silently become tenant-specific application code. Same-version operation and a shared upgrade policy preserve a common product. An unapproved customer-only branch is a rejection signal because it creates release and support divergence.

9) Treat configuration delta and drift separately

Configuration may legitimately vary within an approved envelope. Drift is uncontrolled divergence from that envelope. Record both. Unknown drift evidence is a HOLD; confirmed unmanaged drift can invalidate the footprint until repaired.

10) Observability and backup are part of the footprint

A dedicated deployment that is invisible to common monitoring or lacks a tested backup/restore profile is not operationally ready. Isolation does not excuse missing operational controls.

11) Build the contract as evidence

The working table connects the requirement, dedicated/shared boundary, capacity, cost, automation, version/drift and lifecycle evidence to one bounded state.

12) Negative case: dedicated without a hard reason

If the regulatory or performance constraint disappears but dedicated infrastructure remains, the architecture is not automatically still ELIGIBLE. The reason gate fails. If a compliant pooled option now exists, evaluate migration rather than treating sunk effort as justification.

13) Negative case: a tenant-only branch

A customer-only code branch changes the product boundary, not just the infrastructure boundary. Unless a separate product model has been explicitly authorized elsewhere, this lesson treats that branch as an invalid shortcut and returns REJECT.

14) Transfer: pooled isolation becomes compliant

Six months later the regulation is removed, workload doubles, and the pooled platform gains a compliant isolation control. Recompute from new evidence. If migration is clearly safe and defined, recommend a return to pooled capacity. If migration evidence is incomplete, preserve HOLD even if the target architecture looks preferable.

15) Completion test

You can finish when another reviewer can reproduce the same bounded state from visible evidence: hard reason, dedicated/shared planes, capacity, unit-cost floor, automation, version and upgrade policy, configuration/drift, observability, backup/restore, migration path, decommission trigger and evidence references. Never strengthen the verdict beyond the evidence.