Scope, Contract, SOW, and Acceptance Alignment — Technical reference

This reference owns the implementation contracts of BND-SCOPE. Read the package guide for usage, configuration, dependencies and upgrades. Generic execution, isolation and admission remain governed by Platform Documentation.

Data model and interfaces

DataModelPackage: DM-SCOPE

Owned entities: contract, SOW, clause, requirement, scope item, acceptance criterion, change request, contractual acceptance, authority assessment.

InterfacePackage contributions: IF-SCOPE-ALIGNMENT.

Each business object and source reference remains tenant- and purpose-scoped. The package owns schema evolution and declared migration behavior; the platform enforces schema registration, authorization and versioned installation. Consumers reference this model rather than creating competing canonical copies.

Workflows

WorkflowPackage: WFP-SCOPE-ALIGNMENT

• Contract and SOW Ingestion
• Clause and Deliverable Resolution
• Requirement Alignment
• Scope Classification
• Scope-Change Lifecycle
• Acceptance Detection
• Authority and Formalization Review
• Change-Request Drafting

These are named definitions within the workflow package, not separate invented workflow IDs. Workflow runs resolve package versions, actor and purpose, authorized inputs, retries, review gates and output schemas through the environment lock. Temporal provides durable execution and Kafka carries declared lifecycle/domain events.

Policies, evaluations and tools

POL-CONTRACT-EVIDENCE, EVAL-SCOPE-ALIGNMENT, clause, requirement, comparison, and change-request tools.

Qualification covers the selected model/runtime profile, languages, access scope, failure handling and the package's domain-specific outcomes. Tool execution uses the platform gateway; package code cannot increase its own permissions or write directly to external systems.

Owned agents

B03 — Scope, Contract, and SOW Alignment Agent

Agent ID: effority.scope-contract-alignment

Purpose: Compares conversations and execution evidence with the effective SOW, contract, requirement, deliverable, milestone, and acceptance criteria.

Triggers: Relevant meeting, contract or SOW version, proposed change, acceptance event, or formalization review.

Inputs: Effective clauses, appendices, change requests, plan, transcript excerpts, object links, and authority context.

Outputs: In-scope confirmation, possible scope change, out-of-scope item, contradiction, missing formalization, acceptance classification, clause link, and change-request draft.

Tools: document.clause_read, document.version_resolve, evidence.search, project.read, finding.read, and artifact.derive.

Review and limits: Contractual interpretation and legal effect remain human decisions. Possible contractual acceptance always enters competent review.

Primary metrics: Clause-retrieval accuracy, scope-change precision and recall, acceptance false-positive rate, and formalization coverage.

Implementation profiles

Project, Contract, and SOW Analysis Implementation

Contract documents are indexed by clause, requirement, deliverable, milestone, and acceptance criterion. The temporal resolver selects the version effective on the meeting date.

For each project finding, the system:

1. retrieves the related plan, SOW, RAID, change requests, and reports;
2. links people, deliverables, milestones, and requirements;
3. compares the statement with the recorded status;
4. classifies the relationship as confirmation, deviation, change, contradiction, dependency, or lack of evidence;
5. estimates impact separately for scope, schedule, cost, quality, and relationship;
6. proposes an update or formalization document;
7. requires human review for contractual acceptance, noncompliance, or scope change.

Customer confirmations are stored as events with literal text, speaker, date, and object. The system distinguishes ACKNOWLEDGEMENT, OPERATIONAL_ACCEPTANCE, REQUEST_FOR_CHANGE, and POSSIBLE_CONTRACTUAL_ACCEPTANCE; the last is never confirmed without competent review.

Integration boundaries

A conversational acknowledgement is not automatically contractual acceptance. The package records evidence and required review, not legal conclusions.

Owned screen contracts: SCR-PRJ-05, SCR-PRJ-06.

See solution workflows for cross-package behavior. Screens, agents and workflows keep one canonical owner even when other bundles invoke or enrich them.