Attachment E.docx

Attachment E - Proposed Inspection and Acceptance Terms

E.1 Inspection of Services The State may inspect, test, observe, review, validate, and evaluate all services, deliverables, software and configuration, documentation, reports, data exchanges, security controls, accessibility evidence, operational processes, and other work products at any time during the Contract. Inspection applies solely to the Prime Contractor, who is fully responsible for all work performed by its staff and subcontractors.

Inspection activities may include workstream review, product demonstrations, document review, technical review, security review, accessibility testing, data validation, user acceptance testing, and operational readiness review. The Prime Contractor shall provide immediate access to environments, documentation, logs, test results, security reports, accessibility evaluations, and any other information required to support inspection activities. Failure to provide access upon request may result in withholding of payment or other remedies available to the State.

Inspection will be based on objective, documented criteria and will include verification of service performance, system behavior, security controls, accessibility compliance, and data handling requirements. Any deficiency identified during inspection shall be corrected by the Prime Contractor at no additional cost. The State may establish mandatory correction timelines. Failure to correct deficiencies within the required timeframe may result in rejection of deliverables, escalation, or other remedies available under the Contract.

E.2 Proposed Acceptance Procedures For purposes of this Section, deliverable-based milestones may include one-time implementation activities and work products such as approved planning and design deliverables, architecture, configuration, software development, API and interface development, integration, data-exchange implementation, testing, deployment and cutover, initial training and knowledge transfer, as-built documentation, and other implementation milestones identified in the Contract or applicable pricing schedule.

For purposes of the State’s proposed acceptance procedures, acceptance criteria will be objective, verifiable, and aligned with applicable project Success Factors and Contract requirements. The State will evaluate each applicable deliverable-based milestone, phase, or release for completeness, traceability, accuracy, usability, security and privacy, accessibility, defect resolution, internal consistency, technical accuracy, release alignment, and compliance with the Statement of Work, applicable attachments, standards, frameworks, and specifications. Deliverables must contain the documentation, data, diagrams, evidence, and supporting materials necessary to demonstrate compliance and readiness and must be free of material contradictions, omissions, and unresolved placeholders.

Acceptance criteria shall reflect release alignment. For MVP Release 1 and Release 1.1, applicable acceptance evidence must demonstrate that required functionality, integrations, data flows, security controls, accessibility requirements, user-experience elements, and workflows assigned to the applicable release have been designed, configured, tested, and documented. For future releases, applicable acceptance evidence must identify release designation, sequencing assumptions, and dependencies and demonstrate readiness for implementation without requiring unnecessary rework of accepted MVP Release 1 or Release 1.1 components.

Acceptance criteria shall also reflect the type of deliverable being reviewed, as applicable:

a. Planning and Project Management Deliverables shall accurately reflect the approved schedule, staffing approach, governance model, communication strategy, risk-management processes, and release sequencing.

b. Design and Architecture Deliverables shall accurately document the applicable technical, functional, security, privacy, data-governance, integration, identity, and architecture requirements of the FYF Portal.

c. Configuration, Development, and Integration Deliverables shall accurately reflect the implemented solution and applicable configuration, software development, API and interface development, integration, data-exchange, data-handling, consent, accessibility, security, and sustainment requirements.

d. Testing and Acceptance Deliverables shall document applicable functional, integration, performance, security, accessibility, user-acceptance, and other required testing and provide sufficient evidence to support deployment and release-readiness decisions.

e. Cutover, Transition, and Deployment Deliverables shall document the applicable cutover approach, deployment sequencing, transition activities, and operational-readiness requirements necessary to support implementation without avoidable service interruption.

f. Training and Knowledge-Transfer Deliverables shall be complete, accurate, accessible, plain-language, release-aligned, applicable to the user personas and functionality included in the release, and consistent with the behavior of the production solution.

g. As-Built Documentation and Technical Reference Materials shall accurately document the implemented configuration, architecture, software components, APIs, interfaces, integrations, data exchanges, and operational characteristics necessary for the State to maintain, enhance, support, and govern the solution.

h. On-Demand Deliverables shall be complete, accurate, timely, responsive to the State’s request, and identify applicable release alignment.

The UX and Product Design Package and applicable user-facing functionality shall not be accepted solely because design artifacts, prototypes, or test documents have been delivered. Proposed acceptance shall include evidence, as applicable, that the State-approved User Research and Usability Validation Plan was completed; required representative-user research and validation activities occurred; material findings and recommendation dispositions were documented; identified material usability, accessibility, plain-language, workflow, and user-comprehension issues were corrected, incorporated into a State-approved remediation plan, or expressly accepted by the State; and required traceability was provided.

The Prime Contractor shall submit the evidence required to support acceptance of each Contract-designated deliverable-based milestone, phase, or release. Individual work products or development activities that are components of a larger Contract-designated milestone may be inspected, tested, reviewed, or validated by the State without constituting separate formal acceptance or creating a separate payment obligation.

An incomplete or insufficient evidence package will not begin the applicable acceptance review period. Unless another timeframe is established in the approved project schedule or final Contract, the State will conduct an initial completeness review within fourteen (14) business days after receipt of a complete submission.

Following the completeness review, the State will evaluate the submission for accuracy, completeness, internal consistency, technical alignment, release alignment, and compliance with applicable requirements. The State will provide written notice of acceptance or required corrections within the timeframe established in the approved project schedule or final Contract.

If corrections are required, the Contractor shall revise and resubmit the affected deliverable-based milestone, work product, or supporting evidence at no additional cost to the State unless the deficiency results solely from a State-directed change. Unless another timeframe is approved by the State or established in the final Contract, the Contractor shall resubmit the corrected deliverable within five (5) business days after receipt of State comments. The State will conduct a final review following resubmission.

The State is the authority for formal acceptance. Contractor self-certification does not constitute State acceptance. Unless otherwise expressly provided in the final Contract, acceptance of an individual work product or component does not constitute acceptance of the associated Contract-designated milestone, and acceptance of an individual deliverable-based milestone does not constitute final acceptance of the associated phase, release, or complete implementation.

The State may reject a deliverable-based milestone, phase, or release if the applicable submission is incomplete, inaccurate, materially inconsistent with Contract requirements or applicable release designations, contains material defects or unresolved deficiencies, does not accurately reflect the implemented solution, or is otherwise insufficient to demonstrate compliance with the applicable acceptance criteria.

Final acceptance of a deliverable-based milestone, phase, or release does not waive the State’s rights regarding latent defects, security vulnerabilities, unresolved warranty obligations, inaccurate representations, or Contract nonconformance discovered after acceptance.

E.3 Recurring Service Deliverables and Periodic Acceptance Operations and Maintenance services and, when applicable, subscription-based services shall be treated as recurring or periodic service deliverables in accordance with the service periods established in the final Contract.

For each applicable service period, the Contractor must meet the service levels, performance metrics, reporting obligations, security requirements, availability requirements, monitoring requirements, operational responsibilities, and other performance requirements established in the final Contract.

Under the State’s proposed acceptance approach, recurring service deliverables will be accepted after the State verifies that the applicable service components have been activated, configured, validated, and are operating in accordance with Contract requirements. When subscription-based functionality is included, applicable subscription features must be enabled, configured, validated, and performing in accordance with the final Contract.

The State may reject a recurring service or subscription deliverable that does not demonstrate required activation, configuration, readiness, performance, availability, monitoring, security, accessibility, or operational compliance. Rejected service or subscription deliverables shall be corrected at no additional cost to the State unless the deficiency results solely from a State-directed change.

Failure to meet the applicable requirements may result in non-acceptance, payment withholding, service credits, corrective action, or other remedies established in the final Contract. Acceptance of one service period does not waive the State’s rights regarding deficiencies or nonconformance occurring in another service period or discovered after acceptance.

E.4 State Contract Quality Assurance The State may use quality assurance reviews, workstream reviews, independent reviews, security reviews, accessibility reviews, user acceptance testing, operational readiness reviews, and other verification activities to confirm that the Contractor's work meets Contract requirements. Quality Assurance applies exclusively to the Prime Contractor.

The Contractor shall cooperate with State quality assurance activities and shall correct deficiencies identified by the State within the timeframe directed by the State or agreed through the approved issue management process. If Quality Assurance identifies deficiencies, the Prime Contractor shall correct them immediately at no additional cost.

Repeated deficiencies, failure to correct deficiencies, patterns of nonconformance, or lengthy unresolved deficiencies that extend beyond State defined correction timelines may result in escalation, rejection of deliverables, withholding of payment, service credits, or other remedies available under the Contract. The State may also require a formal remediation plan if deficiencies persist or if the Contractor demonstrates an ongoing inability to meet Contract requirements.

Implementation Quality Gates can also be found in Section C.15.1.6 Quality Assurance findings will directly inform inspection, acceptance decisions, release readiness, and ongoing service period acceptance.

E.4.1 Performance Verification, Evidence, and Auditability The State may conduct audits, reviews, compliance checks, surveys, usability testing, accessibility testing, security testing, synthetic transactions, disaster-recovery observations, data-quality validation, performance testing, and other verification activities at any time. The Contractor shall cooperate fully and shall provide timely access to systems, logs, dashboards, tools, configurations, personnel, subcontractors, work products, raw data, calculations, tickets, communications, and documentation necessary to verify performance.

The Contractor shall provide the State with real-time or near-real-time dashboard access for availability, service health, incident status, performance, integrations, data feeds, security, vulnerabilities, notifications, critical journeys, and SLA attainment. Dashboard access shall not replace required reports or raw data feeds.

The Contractor shall retain the measurement evidence needed to reproduce each reported result for the period required by the Contract, applicable records-retention requirements, and State direction. Measurement evidence shall be complete, time-synchronized, tamper-evident where appropriate, and traceable to the applicable service, journey, incident, release, integration, or data source.

The State’s review, verification, approval, or acceptance of a report does not waive an undiscovered failure, inaccurate calculation, omitted event, or other noncompliance. If a later audit identifies an underreported failure or credit, the State may apply the corresponding fee reduction or remedy retroactively.

Acceptance criteria shall reflect release alignment. For MVP Release 1 and Release 1.1, applicable acceptance evidence must demonstrate that required functionality, integrations, data flows, security controls, accessibility requirements, user-experience elements, and workflows assigned to the applicable release have been designed, configured, tested, and documented. For future releases, applicable acceptance evidence must identify release designation, sequencing assumptions, and dependencies and demonstrate readiness for implementation without requiring unnecessary rework of accepted MVP Release 1 or Release 1.1 components.

Acceptance criteria shall also reflect the type of deliverable being reviewed, as applicable:

a. Planning and Project Management Deliverables shall accurately reflect the approved schedule, staffing approach, governance model, communication strategy, risk-management processes, and release sequencing.

b. Design and Architecture Deliverables shall accurately document the applicable technical, functional, security, privacy, data-governance, integration, identity, and architecture requirements of the FYF Portal.

c. Configuration, Development, and Integration Deliverables shall accurately reflect the implemented solution and applicable configuration, software development, API and interface development, integration, data-exchange, data-handling, consent, accessibility, security, and sustainment requirements.

d. Testing and Acceptance Deliverables shall document applicable functional, integration, performance, security, accessibility, user-acceptance, and other required testing and provide sufficient evidence to support deployment and release-readiness decisions.

e. Cutover, Transition, and Deployment Deliverables shall document the applicable cutover approach, deployment sequencing, transition activities, and operational-readiness requirements necessary to support implementation without avoidable service interruption.

f. Training and Knowledge-Transfer Deliverables shall be complete, accurate, accessible, plain-language, release-aligned, applicable to the user personas and functionality included in the release, and consistent with the behavior of the production solution.

g. As-Built Documentation and Technical Reference Materials shall accurately document the implemented configuration, architecture, software components, APIs, interfaces, integrations, data exchanges, and operational characteristics necessary for the State to maintain, enhance, support, and govern the solution.

h. On-Demand Deliverables shall be complete, accurate, timely, responsive to the State’s request, and identify applicable release alignment.

The UX and Product Design Package and applicable user-facing functionality shall not be accepted solely because design artifacts, prototypes, or test documents have been delivered. Proposed acceptance shall include evidence, as applicable, that the State-approved User Research and Usability Validation Plan was completed; required representative-user research and validation activities occurred; material findings and recommendation dispositions were documented; identified material usability, accessibility, plain-language, workflow, and user-comprehension issues were corrected, incorporated into a State-approved remediation plan, or expressly accepted by the State; and required traceability was provided.

The Prime Contractor shall submit the evidence required to support acceptance of each Contract-designated deliverable-based milestone, phase, or release. Individual work products or development activities that are components of a larger Contract-designated milestone may be inspected, tested, reviewed, or validated by the State without constituting separate formal acceptance or creating a separate payment obligation.

An incomplete or insufficient evidence package will not begin the applicable acceptance review period. Unless another timeframe is established in the approved project schedule or final Contract, the State will conduct an initial completeness review within fourteen (14) business days after receipt of a complete submission.

Following the completeness review, the State will evaluate the submission for accuracy, completeness, internal consistency, technical alignment, release alignment, and compliance with applicable requirements. The State will provide written notice of acceptance or required corrections within the timeframe established in the approved project schedule or final Contract.

If corrections are required, the Contractor shall revise and resubmit the affected deliverable-based milestone, work product, or supporting evidence at no additional cost to the State unless the deficiency results solely from a State-directed change. Unless another timeframe is approved by the State or established in the final Contract, the Contractor shall resubmit the corrected deliverable within five (5) business days after receipt of State comments. The State will conduct a final review following resubmission.

The State is the authority for formal acceptance. Contractor self-certification does not constitute State acceptance. Unless otherwise expressly provided in the final Contract, acceptance of an individual work product or component does not constitute acceptance of the associated Contract-designated milestone, and acceptance of an individual deliverable-based milestone does not constitute final acceptance of the associated phase, release, or complete implementation.

The State may reject a deliverable-based milestone, phase, or release if the applicable submission is incomplete, inaccurate, materially inconsistent with Contract requirements or applicable release designations, contains material defects or unresolved deficiencies, does not accurately reflect the implemented solution, or is otherwise insufficient to demonstrate compliance with the applicable acceptance criteria.

Final acceptance of a deliverable-based milestone, phase, or release does not waive the State’s rights regarding latent defects, security vulnerabilities, unresolved warranty obligations, inaccurate representations, or Contract nonconformance discovered after acceptance.

Request for Proposals No. 5400030161 Attachment E, page 1