## 1. NORMALIZED CONTRACT DATASET | Target Field | Normalized Value | Evidence Status | Source Provenance / Evidence | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Contract ID** | Unresolved / not provided | **MISSING** | Contract repository export is identified as a source, but no Contract ID value was supplied in the provided source data. | | **Contract Title** | **Master Services Agreement** | SUPPORTED / NORMALIZED | Executed agreement PDF: Agreement title = “Master Services Agreement”. | | **Contract Type** | **MSA** | SUPPORTED / NORMALIZED | Repository export: Contract Type = “MSA”. This is a standardized abbreviation consistent with the agreement title, but no broader semantic conversion is necessary beyond retaining the repository classification. | | **Customer / Counterparty** | **Meridian Retail Group, Inc.** | SUPPORTED / NORMALIZED | Executed agreement: “Meridian Retail Group, Inc.”; repository: “Meridian Retail Group”. These are treated as equivalent representations for normalization because the supplied source data identifies the repository form as the corresponding contract-party representation. The full legal name is retained as the normalized value because it is explicitly stated in the executed agreement. | | **Vendor / Supplier** | **Northstar Facilities Solutions, Inc.** | SUPPORTED / NORMALIZED | Executed agreement: “Northstar Facilities Solutions, Inc.”; repository: “Northstar Facilities Solutions”. The supplied representations are normalized to the executed-agreement name. | | **Effective Date** | **2021-03-01** | SUPPORTED / NORMALIZED | Executed agreement: “March 1, 2021”; repository: “03/01/2021”. Difference is representational only. | | **Initial Term** | **3 years** | SUPPORTED / NORMALIZED | Executed agreement: “three (3) years”. | | **Expiration / Current Term End Date** | **UNRESOLVED — competing source value: 2024-02-28** | **CONFLICTING** | Repository export: Expiration Date = “02/28/2024”. Executed agreement states a three-year initial term, but the supplied material does not expressly state the corresponding calendar end date. The evidence provided does not establish that 2024-02-28 is the correct contractual term-end date, nor does it supply an authoritative rule resolving the date calculation. | | **Auto-Renewal** | **Yes — successive 1-year periods unless either party gives at least 90 days' written notice of non-renewal** | SUPPORTED / NORMALIZED | Executed agreement renewal provision; repository: Auto Renewal = “Yes”. | | **Renewal Notice Period** | **90 days** | SUPPORTED / NORMALIZED | Executed agreement: “at least ninety (90) days' written notice of non-renewal”; repository: “90 days”. | | **Contract Status** | **Active** | SUPPORTED / NORMALIZED | Repository export: Contract Status = “Active”. | | **Amendment Status** | **Amended — First Amendment dated 2022-06-15** | SUPPORTED / NORMALIZED | First Amendment: dated June 15, 2022; states the agreement remains in effect and modifies the service schedule and pricing exhibit. | | **Pricing / Commercial Exhibit Status** | **Modified by First Amendment** | SUPPORTED / NORMALIZED | First Amendment states that it modifies the service schedule and pricing exhibit. Exact amended pricing values were not supplied. | ### Source Quality Assessment | Source | Source Type | Condition | Assessment | | ---------------------------------- | ----------- | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Executed Master Services Agreement | PDF | **PARTIALLY USABLE** | Relevant contractual terms and party/date information are supplied, but precise PDF page/section references are not provided in the material available for normalization. | | First Amendment | PDF | **PARTIALLY USABLE** | Amendment date and modification scope are supplied, but precise PDF page/section references and detailed amended commercial values are not provided. | | Contract repository export | Spreadsheet | **USABLE for supplied metadata** | Structured repository values are available for the fields identified in the input. No Contract ID value was supplied. | --- ## 2. QA EXCEPTIONS ### QA-01 — Expiration / Current Term End Date **Exception Type:** CONFLICTING **Field:** Expiration / Current Term End Date **Source Values / Evidence:** * Executed agreement: Initial Term = “three (3) years”. * Repository: Expiration Date = **02/28/2024**. **Normalized Value:** Unresolved. **Reason:** The repository supplies a specific expiration date, while the agreement evidence supplied only states a three-year initial term. The provided material does not expressly establish the contractual calendar end date resulting from that three-year term. Because no explicit date-calculation or precedence rule is supplied, **2024-02-28 cannot be accepted as the unique normalized contractual term-end date**. **Normalization Limitation:** Calculating a calendar end date from “three (3) years” would require applying a date-interpretation convention that has not been expressly supplied. The repository value also cannot be silently treated as controlling merely because it is structured repository data. **Human Validation:** Required. Validate the contractual end-date interpretation and whether the repository date is correct. --- ### QA-02 — Contract ID Missing **Exception Type:** MISSING **Field:** Contract ID **Source Values / Evidence:** No Contract ID was included in the supplied contract data or repository fields. **Normalized Value:** Unresolved / unpopulated. **Reason:** The target schema includes Contract ID, but no supporting value was provided. **Human Validation:** Required if Contract ID is necessary for repository record matching. --- ### QA-03 — Renewal / Current Term End Date Cannot Be Reliably Normalized **Exception Type:** INSUFFICIENT **Field:** Expiration / Current Term End Date **Source Evidence:** The agreement contains an automatic-renewal mechanism for successive one-year periods, while the repository contains an initial expiration value of 02/28/2024. No notice history, non-renewal notice, renewal date record, or later contractual term-end value was supplied. **Reason:** The supplied material does not establish a unique **current** term-end date after the initial term. The automatic-renewal provision means the initial expiration field alone does not establish the current term end. **Human Validation:** Required. A repository administrator or contract professional should validate the applicable renewal cycle and any notice history before a current term-end date is populated. --- ### QA-04 — Detailed Amended Pricing Not Supplied **Exception Type:** INSUFFICIENT **Field:** Pricing / Commercial Exhibit Status **Source Evidence:** First Amendment states that it modifies the service schedule and pricing exhibit. **Normalized Value:** “Modified by First Amendment”. **Reason:** The existence of the amendment to the pricing exhibit is supported, but the actual amended pricing values or complete pricing terms were not supplied. The dataset therefore should not populate detailed pricing information. **Human Validation:** Required if detailed commercial fields are required elsewhere in the repository. --- ### Data Integrity Notes The following differences **are not treated as conflicts**: * `March 1, 2021` vs `03/01/2021` → representational date difference; normalized to `2021-03-01`. * `Northstar Facilities Solutions, Inc.` vs `Northstar Facilities Solutions` → normalized to the executed-agreement representation based on the supplied corresponding-party data. * `Meridian Retail Group, Inc.` vs `Meridian Retail Group` → normalized to the executed-agreement representation. * `three (3) years` vs `3 years` → representational/formatting difference only. * “automatically renews for successive one-year periods...” vs repository `Auto Renewal = Yes` → the agreement supplies the detailed mechanism and the repository supplies the categorical flag; these are not conflicting values. ### Final QA Result The dataset is substantially normalizable, but **the contract term-end information should remain unresolved rather than being forced into a precise date**. The principal validation issue is the repository’s `02/28/2024` expiration value versus the agreement’s supplied three-year initial-term language, together with the absence of renewal/notice history needed to establish a current term end.