Contract Suite Concepts: MSA/SOW/SLA/Scope

This lesson is not a contract-drafting exercise. It builds an auditable decision model that can say which document and version owns a scope, acceptance, performance, change or conflict claim. The primary artifact is Contract Suite Scope, Performance & Change-Control Matrix v1.

Scenario: a managed-agent service has a framework agreement, an implementation SOW and a performance SLA. A customer requests a new integration and argues that because the SLA says the service is supported, the integration must already be in scope. The answer must come from evidence—not from a familiar label or a convenient sentence.

Boundary: a mention in an MSA or SLA is not automatically scope proof; a performance commitment is not a scope expansion.

Route orientation and owned boundary

AGN-008 owns the separation of framework terms, scoped work, acceptance, SLA performance and change control. It does not absorb AGN-007 cost metering or AGN-009 privacy/DPA.

Foundation learners get a field map and a worked case. Experienced learners may compress terminology, but they must satisfy the same evidence bar for document authority, conflict, change and transfer.

Mental model: a contract suite is not one undifferentiated blob

Keep four layers distinct:

1. Framework layer — umbrella/shared terms.
2. Scope/delivery layer — SOW or approved change; work, owner, period, deliverable and acceptance.
3. Performance layer — SLA metric, target, measurement window/source and remedy reference.
4. Change/conflict layer — change request, approval, priority rule, conflict and escalation.

This separation is a governance design, not a universal rule of contract law.

Foundations: FACT versus DESIGN

NIST describes an SLA as a provider/customer commitment that may address responsibilities, service details, expected performance and reporting/resolution/termination. That is useful terminology and performance evidence; it does not decide enforceability for a specific agreement.

FAR 8.405-2, in a specific U.S. federal acquisition context, lists SOW elements such as work description, location, period of performance, deliverable schedule, performance standards and special requirements. We use that as a structured evidence reference, not as universal private-contract law.

Document priority, approval states, remedies and legal-review triggers must come from local authority or qualified review.

Deep contract explanation

The artifact has 19 critical dimensions: contract_suite_id, the MSA/SOW/SLA references, scope_version, scope_item_id, deliverable_id, acceptance_criteria_ref, acceptance_state, service_metric_id, service_target, measurement_source, change_request_id, change_approval_state, document_priority_rule_ref, conflict_state, legal_review_required, evidence_ref, and audit_ref.

Key gates:

• Out-of-scope requests require change control; SLA wording cannot make them in-scope.
• A deliverable moved into an unapproved change cannot remain acceptance_state=APPROVED.
• A changed measurement window invalidates the old metric result until recomputed.
• Real document conflict cannot remain conflict_state=CLEAR.
• Priority rules and remedies require explicit authority references.
• Transfer cases must be recomputed; the baseline decision is never an oracle.

Worked examples

1. New integration request

The current SOW does not include the integration; the SLA discusses service availability. Record OUT_OF_SCOPE, open change control, and keep the SLA in the performance layer. Bounded result: SCOPE_CHANGE_REVIEW_READY.

2. Existing in-scope deliverable

When the deliverable is in the current scope, criteria are explicit and acceptance evidence is current, APPROVED can be defensible for that deliverable only.

3. Transfer

A second suite keeps the same SLA metric but changes the SOW schedule and adds a customer dependency. Rebuild the decision from the new evidence; do not reuse the prior label.

Failure modes

• Treating SLA wording as scope authority.
• Treating any MSA mention as a committed deliverable.
• Keeping acceptance approved after work moved to an unapproved change.
• Reusing an SLA result after the measurement window changed.
• Hiding contradictory documents under conflict_state=CLEAR.
• Inventing a priority rule or remedy without an authoritative reference.
• Using the baseline decision as the transfer oracle.

Alternatives and trade-offs

There is no required number of contract documents in this lesson. A smaller suite can be simpler; a more modular suite can improve traceability but adds change-control overhead. Even if one document serves multiple roles, the evidence roles must remain distinguishable: what proves scope, what proves acceptance, what defines performance, and what authorizes a change? If that cannot be shown, preserve HOLD/REVIEW.

Experienced bridge

If the vocabulary is familiar, skip the definitions and answer three questions:

1. Does every obligation have a governing source and version?
2. Are acceptance and SLA results current and evidence-bound?
3. Which states must be recomputed when documents or context change?

Experience never waives the evidence bar.

Guided and independent practice

Open derived_text/tables/AGN-008-T1.csv, compare the three scenarios, then run:

python -B lab/AGN-008-LAB1/learner/run_checks.py

For independent practice, ignore decision labels and reconstruct state only from the visible fields. Create a new case where the SLA metric stays constant while the SOW schedule or customer dependency changes.

Verification evidence

A prose answer is not enough. Pass evidence includes the complete matrix, traceable source boundaries, at least one negative case and an independently recomputed transfer. The lab must reject shortcuts such as SLA_ONLY => IN_SCOPE, pending change + approved acceptance, and changed measurement window + old result.

Every decision must be reproducible from visible evidence; hidden reasoning is not evidence.

Assessment and transfer

Assessment covers boundary retrieval, baseline application, mutation diagnosis and transfer. In transfer, the second suite keeps the same SLA metric but has a different delivery schedule and an explicit customer dependency. Scope, acceptance, change-control and performance states must be recomputed from the new documents.

Copying the baseline decision fails transfer even when the final label happens to match.

References, freshness and legal boundary

• NIST CSRC Glossary — Service Level Agreement: terminology/performance expectations.
• Acquisition.gov FAR 8.405-2: official SOW-element example in a U.S. federal context.
• Frozen Lesson Bible lesson://AGN-008: local MAKNOW authority for the state vocabulary and governance design.

This lesson is not legal advice. Document priority, remedies, enforceability and real contract language require qualified organizational/legal authority. Recheck external sources by 2026-11-14 or earlier on material change.