VOLUME II - Attachment A - Plagiarism Detection - Technical Proposal.xlsx
XLSX spreadsheet 335 KB Posted
- Attached to
- Plagiarism Detection Solution
- Solicitation number
- 2136499
- Issued by
- New York County, Nissequogue Village, New York
About this file
This is a technical proposal attachment for a Request for Proposals (RFP) issued by the City University of New York (CUNY) system to procure a comprehensive plagiarism detection and academic integrity platform. The document establishes mandatory and highly desired functional and technical requirements that prospective vendors must address in their proposals. The plagiarism detection solution must include real-time detection leveraging web, academic, and institutional databases with a minimum 95% accuracy rate for identifying paraphrased, translated, and AI-generated content, as well as cross-submission and cohort-based comparison capabilities. Additional core functional requirements include text manipulation detection across multiple languages, interactive similarity reports with customizable thresholds, authorship verification and stylometrics analysis, segregated multi-campus environments with unique settings and permissions, comprehensive reporting and analytics dashboards, and implementation support including testing, LMS integration, and go-live assistance. The RFP mandates extensive training services of up to 75 hours covering administrator training, end-user train-the-trainer models, ad-hoc training for future enhancements, training manuals, video guides, and self-service resources in accessible formats compliant with Section 508 and WCAG requirements.
Technical requirements specify 24/7 end-user and administrator support via multiple channels with defined Service Level Agreements including response times ranging from one hour for Priority I incidents to two business days for general inquiries. The solution must maintain 99.5% uptime per month with no more than 16 hours of scheduled maintenance outside business hours and support full integration with CUNY's existing ecosystem through LTI 1.3 integration with Brightspace by D2L, RESTful API access, Single Sign-On via SAML 2.0, OAuth 2.0, and LDAP protocols, and role-based user provisioning. The platform must comply with Section 508 of the Rehabilitation Act, WCAG 2.2 AA standards, FERPA and GDPR requirements, and CUNY's cybersecurity policies including SOC 2 Type II or SSAE 18 reporting with TLS 1.2 or higher encryption in transit and AES-256 encryption at rest. The RFP indicates that TurnitIn, LLC is the incumbent vendor, with Service-Disabled Veteran-Owned Business (SDVOB) and Minority/Women Business Enterprise (MWBE) contracting goals of 6% and 30%, respectively.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Table of Contents Exhibit - Plagiarism Detection Platform
| Tab | Section |
| 1 | Requirements Overview |
| 2 | Response Instructions for Potential RFP Respondents |
| 3 | Functional Requirements |
| 4 | Technical Requirements |
UCO-963 - Learning Management System (LMS) Archiving Solution
D2L-K16-UCO-963-Attachment A - Mandatory and Highly Desired Solution Requirements Page &P of &N
1. Overview
| Student Success Platform Solution | |
| Requirement # | Reference number assigned to each discrete system requirement |
| Requirement Status | The status of each requirement is either "Mandatory" or "Highly Desired". Solutions that do not meet Mandatory requirements will be judged non-compliant. Solutions with the ability to satisfy highly desired requirements will be evaluated favorably. |
| Requirement | Description of system requirement |
| Does Solution Meet Requirement? | This field is for completion by RFP respondents. It features a drop-down menu with three options for describing the extent to which the proposed solution will fulfill each requirement: |
| §Completely: The vendor’s system can completely fulfill the requirement | |
| §Partially: The vendor’s proposed system can partially fulfill the requirement | |
| §Not at All: The vendor’s system cannot fulfill the requirement at all | |
| How Does Solution Meet Requirement? | This field is for completion by RFP respondents. It features a drop-down menu with four options for describing the method by which the proposed solution will fulfill each requirement. |
| §Out-of-the-box: The vendor’s system can fulfill the requirement without additional configuration, customization, or development | |
| §Configuration: The vendor’s system can fulfill the requirement by making changes using established product configuration tools (e.g., without using custom code) | |
| §Customization: The vendor’s system can fulfill the requirement by making changes outside of established product configuration tools (e.g., using custom code) | |
| §Development Required: The vendor’s system can fulfill the requirement by undertaking additional development such as integration with third party tools | |
| Comments | This field is for completion by RFP respondents. This field is for respondents to provide additional context for their responses. |
Archiving Solution
D2L-K16-UCO-963-Attachment A - Mandatory and Highly Desired Solution Requirements Page &P of &N
2. Response Instructions
| Respondents must indicate the fit of their proposed services and solution to the specified requirements. | |
| Choose the code that represents the degree the specific requirement is met by proposal. If "N (Not at all)" is selected, do not complete the "How?" | |
| Response Codes | Definition - "Meet Requirement?" |
| C (Completely) | Requirement will be met in full. |
| P (Partially) | Requirement will be partially met, as explained in the comments field with potential workaround solutions, as warranted. |
| N (Not at all) | Requirement will not be met. |
| Respondents must indicate how their proposed services and solution will meet the specified requirements. | |
| How Requirement is met by proposal | |
| Response Codes | Definition - "How?" |
| Out-of-the-Box | System will provide required capabilities with no configuration required. |
| Configuration | System will provide required capabilities with configuration using standard configuration tools, excluding scripting tools. |
| Customization | System will provide required capabilities through customization of source code and components. |
| Integration | System will provide required capabilities only through integration with 3rd party software product. |
Archiving Solution
D2L-K16-UCO-963-Attachment A - Mandatory and Highly Desired Solution Requirements Page &P of &N
3. Functional Requirements
| Plagiarism Detection | ||||||||
| Req # | Req Status | Requirement | Category | RFP Section | Does Solution Meet Requirement? | How Does Solution Meet Requirement? | Comments | |
| FUNC-001 | Mandatory | Real-time plagiarism detection leveraging web, academic, and institutional databases | A. Core Functional Requirements | 3.2.A.1 | ||||
| FUNC-002 | Mandatory | Accuracy Rates for Plagiarism Detection: The solution must maintain a minimum detection accuracy rate of 95%, including the identification of paraphrased, and translated, and AI-generated content, .cross-submission and cohort-based comparison to detect collusion | A. Core Functional Requirements | 3.2.A.2 | ||||
| FUNC-003 | Mandatory | Text manipulation detection (e.g., white text, character substitution, spacing anomalies) | A. Core Functional Requirements | 3.2.A.3 | ||||
| FUNC-004 | Mandatory | Contextual and translated similarity detection across multiple languages | A. Core Functional Requirements | 3.2.A.4 | ||||
| FUNC-005 | Mandatory | Interactive similarity reports with match highlighting, exclusion options, and comment tagging | A. Core Functional Requirements | 3.2.A.5 | ||||
| FUNC-006 | Mandatory | Customizable thresholds, scoring, and review statuses (e.g., Accept/Reject/Revise) | A. Core Functional Requirements | 3.2.A.6 | ||||
| FUNC-007 | Mandatory | Feedback tools including rubric integration, inline comments, and downloadable reports | A. Core Functional Requirements | 3.2.A.7 | ||||
| FUNC-008 | Mandatory | Authorship Verification and Stylometrics (Preferred but not required) | ||||||
| b.1 Stylometric comparison across verified student writing samples | A. Core Functional Requirements | 3.2.A.8.b1 | ||||||
| FUNC-009 | Mandatory | Authorship Verification and Stylometrics (Preferred but not required) | ||||||
| b.2 Metadata analysis (file creation/edit times, author ID, tool usage) | A. Core Functional Requirements | 3.2.A.8.b2 | ||||||
| FUNC-010 | Mandatory | Authorship Verification and Stylometrics (Preferred but not required) | ||||||
| b.3 Identification of anomalies and discrepancies in writing style or document origin | A. Core Functional Requirements | 3.2.A.8.b3 | ||||||
| FUNC-011 | Mandatory | Authorship Verification and Stylometrics (Preferred but not required) | ||||||
| b.4 Reporting interface for manual investigation or escalation | A. Core Functional Requirements | 3.2.A.8.b4 | ||||||
| FUNC-012 | Mandatory | Segregated environments for each CUNY campus with unique settings, roles, and permissions | B. Multi-Institution Settings | 3.2.B.1 | ||||
| FUNC-013 | Mandatory | Configurable workflows and policies per institution without cross-campus data visibility | B. Multi-Institution Settings | 3.2.B.2 | ||||
| FUNC-014 | Mandatory | Global administrator interface for CUNY Central to monitor license usage and aggregate reporting | B. Multi-Institution Settings | 3.2.B.3 | ||||
| FUNC-015 | Mandatory | Instructor and administrator dashboards for tracking submissions, reports, and outcomes | C. Reporting & Analytics | 3.2.C.1 | ||||
| FUNC-016 | Mandatory | Exportable data and reports (e.g., Excel, PDF, CSV) | C. Reporting & Analytics | 3.2.C.2 | ||||
| FUNC-017 | Mandatory | Usage analytics and trend reports, including AI authorship rates and similarity score distribution | C. Reporting & Analytics | 3.2.C.3 | ||||
| FUNC-018 | Mandatory | Cohort-level comparison and audit trails for academic integrity monitoring | C. Reporting & Analytics | 3.2.C.4 | ||||
| FUNC-019 | Mandatory | Implementation plan including testing, LMS integration, configuration, and go-live support | D. Implementation & Transition Plan | 3.2.D.1 | ||||
| FUNC-020 | Mandatory | Post-go-live support, performance monitoring, and update management | D. Implementation & Transition Plan | 3.2.D.2 | ||||
| FUNC-021 | Mandatory | As part of the continuous growth and improvement of systems and technologies, CUNY expects that during the term of the contract, Contractor will: | ||||||
| a. notify CUNY of any system enhancements and features for CUNY stakeholders to decide if this can be deployed in the CUNY environment and when it should be deployed | E. Enhancements and Features | 3.2.E.1a | ||||||
| FUNC-022 | Mandatory | As part of the continuous growth and improvement of systems and technologies, CUNY expects that during the term of the contract, Contractor will: | ||||||
| b. allow CUNY to enable/disable or deploy any features (including any AI Feature) that may be available in the platform, so it is unusable by any user of the system | E. Enhancements and Features | 3.2.E.1b | ||||||
| FUNC-023 | Mandatory | As part of the continuous growth and improvement of systems and technologies, CUNY expects that during the term of the contract, Contractor will: |
c. involve CUNY in validating new features, pilot deployments, or A/B testing—prior to production rollout.
| 1. Scope of the pilot (e.g., number of users and campuses). | E. Enhancements and Features | 3.2.E.1c.1 | |
| FUNC-024 | Mandatory | As part of the continuous growth and improvement of systems and technologies, CUNY expects that during the term of the contract, Contractor will: |
c. involve CUNY in validating new features, pilot deployments, or A/B testing—prior to production rollout.
| 2. Feedback mechanisms for participants including surveys and focus groups. | E. Enhancements and Features | 3.2.E.1c.2 | |
| FUNC-025 | Mandatory | As part of the continuous growth and improvement of systems and technologies, CUNY expects that during the term of the contract, Contractor will: |
c. involve CUNY in validating new features, pilot deployments, or A/B testing—prior to production rollout.
| 3. Success criteria for moving to full deployment. The success criteria is based on the requirements that CUNY specifies as part of the scope of the pilot. | E. Enhancements and Features | 3.2.E.1c.3 | |
| FUNC-024 | Mandatory | Onboarding services and up to 75 hours of training for administrators, instructors, and support staff. |
Training types should include the following:
| a. Administrator Training | F. Training | 3.2.F.1a | |
| FUNC-025 | Mandatory | Onboarding services and up to 75 hours of training for administrators, instructors, and support staff. |
Training types should include the following:
| b. End-User Training (Train-the-Trainer model) | F. Training | 3.2.F.1b | |
| FUNC-028 | Mandatory | Onboarding services and up to 75 hours of training for administrators, instructors, and support staff. |
Training types should include the following:
| c. Ad-hoc training (for future enhancements, features) | F. Training | 3.2.F.1c | |||
| FUNC-029 | Mandatory | Provision of training manuals, video guides, and self-service resources. | F. Training | 3.2.F.2 | |
| FUNC-030 | Mandatory | Live and asynchronous delivery methods, including materials provided | F. Training | 3.2.F.3 | |
| FUNC-031 | Mandatory | Written step-by-step help guides and recorded video tutorials for all features and interfaces of the product suite for end-users who will be utilizing the system. | F. Training | 3.2.F.4 | |
| FUNC-032 | Mandatory | All training material must be available for CUNY to own, take, and modify as needed for internal purposes | F. Training | 3.2.F.5 | |
| FUNC-033 | Mandatory | The Contractor must provide comprehensive end-user and technical administrator training consistent with Section 508 and WCAG requirements, available in accessible formats (e.g., PDF/HTML with captions and alt-text) and supporting diverse learning modes (live, virtual, asynchronous). | F. Training | 3.2.F.6 |
Archiving Solution
D2L-K16-UCO-963-Attachment A - Mandatory and Highly Desired Solution Requirements Page &P of &N
4. Technical Requirements
| Plagiarism Detection Platform | |||||||
| Req # | Req Status | Full Requirement Text | Category | RFP Section | Does Solution Meet Requirement? | How Does Solution Meet Requirement? | Comments |
| TECH-001 | Mandatory | 24/7 end-user and administrator technical support via phone, email, and chat | G. Support and Maintenance | 3.2.G.1 | |||
| TECH-002 | Mandatory | Access to a support portal, product documentation, and release notes | G. Support and Maintenance | 3.2.G.2 | |||
| TECH-003 | Mandatory | Support for feature requests, roadmap engagement, and regular maintenance updates | G. Support and Maintenance | 3.2.G.3 | |||
| TECH-004 | Mandatory | Defined SLA response times, case prioritization, and escalation management (e.g. response within 2 hours for high-priority cases; low-medium difficulty cases are closed within 24 hours; tier 2 and 3 tickets automatically escalated to CUNY CIS for shared response) | G. Support and Maintenance | 3.2.G.4 | |||
| TECH-005 | Mandatory | The platform must support modular enhancements, allowing CUNY to adopt new feature sets or service packages as they become available. The contract shall include provisions to amend scope and pricing to accommodate such additions during the contract term, without requiring a re-procurement, provided they align with the original intent and functional scope. | G. Support and Maintenance | 3.2.G.5 | |||
| TECH-006 | Mandatory | All web and digital content must conform to Section 508 of the Rehabilitation Act, NY Executive Law § 170-f, and the most current version of the Web Content Accessibility Guidelines (WCAG 2.2 AA or successor). Vendors must provide a current Accessibility Conformance Report (ACR) or Voluntary Product Accessibility Template (VPAT) reflecting the current software release. | Accessibility | 3.2.H.1.a | |||
| TECH-007 | Mandatory | The solution must integrate with CUNY Login (Oracle Access Management), supporting Single Sign-On (SSO) using SAML 2.0, OpenID Connect (OIDC), or OAuth 2.0, and must support CUNY’s session management, attribute mapping (emplID, email, roles), and Single Logout requirements. | Authentication and Access Control | 3.2.H.1.b | |||
| TECH-008 | Mandatory | The solution must adhere to CUNY’s Service Provider Standard and cybersecurity policies, including annual submission of SOC 2 (Type II) or SSAE 18 reports (and PCI compliance reports if applicable). All data must be encrypted in transit (TLS 1.2 or higher) and at rest (AES-256), with layered protection and incident-response protocols consistent with the CUNY Information Security framework. | IT Security | 3.2.H.1.c | |||
| TECH-009 | Mandatory | The solution must support robust integration with CUNY’s ecosystem, specifically |
| 1. Full LTI 1.3 integration with Brightspace by D2L, with support for assignments, quizzes, and discussions | Integration with Enterprise Systems | 3.2.H.1.d.1 | |
| TECH-010 | Mandatory | The solution must support robust integration with CUNY’s ecosystem, specifically |
| 2. RESTful API access for integration with external systems (e.g., SIS, data warehouses) | Integration with Enterprise Systems | 3.2.H.1.d.2 | |
| TECH-011 | Mandatory | The solution must support robust integration with CUNY’s ecosystem, specifically |
| 3. Operable as a standalone solution via secure web-based portal with equivalent functionality | Integration with Enterprise Systems | 3.2.H.1.d.3 | |
| TECH-012 | Mandatory | The solution must support robust integration with CUNY’s ecosystem, specifically |
| 4. Real-time synchronization of course rosters, submissions, and grades | Integration with Enterprise Systems | 3.2.H.1.d.4 | |
| TECH-013 | Mandatory | The solution must support robust integration with CUNY’s ecosystem, specifically |
| 5. Support for Single Sign-On (SSO) using protocols including SAML 2.0, OAuth 2.0, and LDAP | Integration with Enterprise Systems | 3.2.H.1.d.5 | |
| TECH-014 | Mandatory | The solution must support robust integration with CUNY’s ecosystem, specifically |
| 6. Role-based user provisioning and automatic account creation through institutional identity management | Integration with Enterprise Systems | 3.2.H.1.d.6 | |||
| TECH-015 | Mandatory | The Contractor must adhere to CUNY’s project-management standards, including providing a comprehensive project plan, risk log (RAID), governance documentation, testing strategy, and change-order approval process. Status reports must include progress, risks, and resource utilization. | Project Management | 3.2.H.1.e | |
| TECH-016 | Mandatory | The Contractor must maintain at least 99.5 percent uptime per month, with no more than 16 hours of scheduled maintenance outside of business hours, and must provide 24 × 7 monitoring and escalation procedures. Initial support-response times shall meet the following standards: | |||
| a. Priority I (Service Unavailable): 1 hour | Service Standards | 3.2.H.1.f.a | |||
| TECH-017 | Mandatory | The Contractor must maintain at least 99.5 percent uptime per month, with no more than 16 hours of scheduled maintenance outside of business hours, and must provide 24 × 7 monitoring and escalation procedures. Initial support-response times shall meet the following standards: | |||
| b. Priority II (Major Module Down): 2 hours | Service Standards | 3.2.H.1.f.b | |||
| TECH-018 | Mandatory | The Contractor must maintain at least 99.5 percent uptime per month, with no more than 16 hours of scheduled maintenance outside of business hours, and must provide 24 × 7 monitoring and escalation procedures. Initial support-response times shall meet the following standards: | |||
| c. Priority III (Function Degraded): 1 business day | Service Standards | 3.2.H.1.f.c | |||
| TECH-019 | Mandatory | The Contractor must maintain at least 99.5 percent uptime per month, with no more than 16 hours of scheduled maintenance outside of business hours, and must provide 24 × 7 monitoring and escalation procedures. Initial support-response times shall meet the following standards: | |||
| d. Priority IV (General Inquiry): 2 business days. | Service Standards | 3.2.H.1.f.d | |||
| TECH-020 | Mandatory | The solution must conform to accessibility and privacy requirements, including: |
| 1. FERPA and GDPR compliance, with clear data ownership and deletion protocols | Accessibility, Privacy, and Security | 3.2.I.1 | |
| TECH-021 | Mandatory | The solution must conform to accessibility and privacy requirements, including: |
| 2. Role-based access controls and detailed audit trails | Accessibility, Privacy, and Security | 3.2.I.2 | |
| TECH-022 | Mandatory | The solution must conform to accessibility and privacy requirements, including: |
| 3. Demonstrate full functional parity between native apps and modern mobile browsers; resolve layout issues on up-to-date iOS/Android browsers | Accessibility, Privacy, and Security | 3.2.I.3 | |
| TECH-023 | Mandatory | The solution must conform to accessibility and privacy requirements, including: |
| 4. Commit to continuous mobile/responsive QA with quarterly accessibility regression testing | Accessibility, Privacy, and Security | 3.2.I.4 | |
| TECH-024 | Mandatory | The solution must conform to accessibility and privacy requirements, including: |
| 5. Full functional parity between native mobile apps and modern mobile browsers | Accessibility, Privacy, and Security | 3.2.I.5 | |
| TECH-025 | Mandatory | The solution must conform to accessibility and privacy requirements, including: |
6. Vendor must conduct quarterly accessibility regressions to ensure WCAG 2.2 conformance for all mobile surfaces Accessibility, Privacy, and Security 3.2.I.6
Archiving Solution
D2L-K16-UCO-963-Attachment A - Mandatory and Highly Desired Solution Requirements Page &P of &N image1.png
File details come from the government source that posted it. Updated .