Attachment 4.xlsx
XLSX spreadsheet 112 KB Posted
- Attached to
- FIND YOUR FUTURE PORTAL State and local contract opportunity
- Solicitation number
- 5400030161
- Issued by
- Richland County, South Carolina
About this file
This is a Technical Requirements Addendum (Attachment 4) for the Find Your Future Portal, a comprehensive digital platform initiative for the State of South Carolina. The document serves as a multitab evaluation instrument that vendors must submit as part of their proposal package and establishes detailed technical specifications across nine functional areas: Security, Identity, and Audit; Network; System Administration and Management; Storage; Application Architecture and Integration; Application Development and Configuration; Data, Reporting, and Analytics; Support and SLAs; and Technical Proposal Response. The Find Your Future Portal is designed to function as South Carolina's unified digital front door integrating education, workforce development, support services, employer engagement, and policy resources across multiple state agencies and partner systems. Vendors must indicate whether their proposed solution meets each of 84 specific security and identity requirements, 14 network requirements, 48 administration and business continuity requirements, 22 storage requirements, 77 architecture and integration requirements, 66 application development and usability requirements, 40 data and reporting requirements, and 50 support and SLA requirements, with detailed commentary explaining compliance and applicable cross-references to supporting documentation.
The Technical Requirements Addendum requires vendor responses to 49 detailed technical proposal questions addressing deployment architecture, user research and co-design methodology, data management and migration capabilities, integration approaches with CRM, LMS, and HCM systems, visual and user experience artifacts, encryption and identity management protocols, logging and security controls, application development tools and environments, analytics capabilities, artificial intelligence features and governance, and security documentation and compliance procedures. The document emphasizes critical architectural requirements including modular cloud-based orchestration supporting federated identity across multiple authentication methods (My SC.GOV, ID.me, Login.gov, SAML 2.0, OAuth 2.0, OpenID Connect); comprehensive audit logging of all transactions, AI-assisted actions, community moderation events, and job posting workflows; role-based and context-aware access controls for nine distinct user personas; real-time performance monitoring and 99.99% uptime guarantees; disaster recovery capabilities with defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO); and support for unlimited State-approved integrations without product-tier limitations. The solution must maintain strict data governance separating user-entered portal data from externally accessed volatile session-based data, enforce consent-driven access controls, support youth-protection and age-gating controls for minor users, prevent unauthorized AI actions through closed-loop controls, and comply with all applicable federal and state privacy regulations including FERPA, state data-sharing agreements, and executive directives within 60 calendar days of notification.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| Attachment J.docx | DOCX document | |
| Exhibit B.xlsx | XLSX spreadsheet | |
| Attachment 5.xlsx | XLSX spreadsheet | |
| Attachment 1.xlsx | XLSX spreadsheet | |
| Schedule B.docx | DOCX document | |
| Attachment I.docx | DOCX document | |
| Schedule A.docx | DOCX document | |
| Attachment E.docx | DOCX document | |
| Attachment 3.xlsx | XLSX spreadsheet | |
| Attachment C.docx | DOCX document | |
| Attachment K.docx | DOCX document | |
| Attachment 2.xlsx | XLSX spreadsheet | |
| Attachment L.xlsx | XLSX spreadsheet | |
| Attachment 6.xlsx | XLSX spreadsheet | |
| Solicitation 5400030161.docx | DOCX document | |
| Exhibit A.docx | DOCX document | |
| Exhibit C.xlsx | XLSX spreadsheet |
Show all 17
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions Attachment 4 - Technical Requirements Addendum
| Respondent |
| [Enter Respondent's Name Here] |
| Table of Contents |
| -Security, Identity, Audit |
-Network -System Admin-Mgmt.
-Storage -App Arch-Integration -App Dev-Config -Data, Reporting -Support, SLAs -Tech Proposal Response
INSTRUCTIONS:
This multi‑tab addendum must be submitted as part of the vendor’s package and will inform the evaluation process. It cannot serve as a substitute for any required RFP response. Vendors remain responsible for submitting all RFP‑mandated materials in the format and structure prescribed. A description and expectations for completing each tab is described below:
1 - Tech Requirements: A series of tabs lists specific technical requirements in the areas of security/identity management/audit, network, system admin/management, storage, architecture and integration, app dev/config management, data/reporting, and support/SLAs. Indicate if your proposed solution/product version/release meets these requirements. Provide appropriate details in the Comments column. For any Attachment 5 requirement necessary to support an MVP Release 1 or Release 1.1 requirement, identify the applicable Attachment 7 ReqID(s) or requirement cluster in the Comments column.
2 - Tech Proposal Response: This tab lists questions requesting additional details on your technical solution(s). Responses to the Tech Proposal Response tab are required. The Offeror may provide detailed supporting information in a consolidated Technical Response document in Volume II; however, each item on this tab must contain either a complete response or a specific cross-reference to the applicable section of that document.
Security, Identity, Audit
| Software Technical Requirements | ||||
| Security, Identity, and Audit | ||||
| # | Sub-Process / Topic | Requirement | Requirement Met? (Fully Met, or Not Met) | Comments |
| 1 | Audit | Ability to generate an audit record for all records and transactions including, but not limited to privileged accounts, User ID, date/time stamp, and old/new field value for changes | ||
| 2 | Audit | Ability to retain audit records for all records and transactions for a defined time period | ||
| 3 | Audit | Ability to provide user-defined audit features for all transactions in solution including, but not limited to all historical changes (ability to tie back what has been changed back to supporting change documentation) | ||
| 4 | Audit | Ability to prevent audit records from being deleted or altered, except as part of a system administration archival process | ||
| 5 | Audit | Ability for audit-tracking reports including, but not limited to user access, usage logs, and key organization data structures | ||
| 6 | Audit | Ability to archive and restore audit logs | ||
| 7 | Audit | Ability to log external access and tie to users, transactions, processes, interfaces, etc. | ||
| 8 | Audit | Ability to generate security/user access reports detailing user roles, associated permissions, workflow approval thresholds, etc. | ||
| 9 | Audit | Ability to maintain immutable audit logs for all AI-assisted actions, including generated content, user approvals or rejections, model inputs, model outputs, timestamps, and human-in-the-loop review actions. | ||
| 10 | Audit | Ability to log all community and mentorship moderation events, user reports, content flags, quarantines, administrative review actions, and appeal decisions with full traceability. | ||
| 11 | Audit | Ability to maintain audit history for employer job posting creation, edits, approvals, multi-board distribution, posting status changes, corrections, resubmissions, withdrawals, expirations, and closures. | ||
| 12 | Identity | Ability to provide administrative web interface for Application Administration | ||
| 13 | Identity | Ability to support federated identity across multiple partner systems using SAML 2.0, OAuth 2.0, and OpenID Connect, including “passport” single sign-on enabling seamless user navigation across external applications | ||
| 14 | Identity | Ability to provide user login credentials that are secured and encrypted at rest across all nine FYF user personas (e.g., job seekers, veterans, employers, students, and state agency staff) | ||
| 15 | Identity | Solution shall have directory synchronization | ||
| 16 | Identity | Ability to use JSON/REST user management API(s) | ||
| 17 | Identity | Solution shall have authorization policy management | ||
| 18 | Identity | Solution shall have entitlement management | ||
| 19 | Identity | Solution shall have delegated administration | ||
| 20 | Identity | Solution shall have appropriate privacy policy | ||
| 21 | Identity | Solution shall have granular authorization support | ||
| 22 | Identity | Solution shall have proprietary access API | ||
| 23 | Identity | Ability to provide consumer identity management capabilities including secure password reset, multi-factor authentication, multi-channel identity verification (email, SMS, push), and identity proofing for public users | ||
| 24 | Identity | Ability to implement and customize Multifactor authentication (MFA) | ||
| 25 | Identity | Solution shall have System for Cross-Domain Identity Management (SCIM) support | ||
| 26 | Identity | Ability to support role-based, persona-based, and context-aware access controls for diverse user populations (e.g., students, job seekers, employers, partner agencies), including dynamic permissions across integrated systems | ||
| 27 | Identity | Ability to map application layer user security roles/groups to AD groups for user provisioning | ||
| 28 | Identity | Ability to support Active Directory integration for user provisioning/deprovisioning, rights assignment and authentication | ||
| 29 | Identity | Ability to support SAML2.0 | ||
| 30 | Identity | Ability to pass AD groups in the assertion for rights assignments | ||
| 31 | Identity | Ability to support automated user deprovisioning for terminations | ||
| 32 | Identity | Ability to support federated identity brokering across multiple independent identity providers | ||
| 33 | Identity | Ability to maintain user session continuity and state across multiple external applications | ||
| 34 | Identity | Ability to support user consent-driven identity and data sharing across partner systems | ||
| 35 | Identity | Ability to support federated authentication and Single Sign-On through My SC.GOV and other State-approved providers such as ID.me or Login.gov while also supporting secure alternative authentication methods for users who do not use SSO. | ||
| 36 | Identity | Ability to allow users to switch between SSO and non-SSO authentication methods without loss of data, loss of account continuity, or loss of access to approved portal functionality. | ||
| 37 | Identity | Ability to manage guardian-learner and parent/dependent account relationships, including role-based permissions, age-based access rules, youth-protection controls, and consent requirements. | ||
| 38 | Identity | Ability to configure consent persistence rules so that user approvals may be required for each use, remain in effect until revoked, or require renewal after a defined period or condition. | ||
| 39 | Identity | Ability to make original consent records clearly documented, visible to the user, and revocable at any time without unnecessary duplicate consent collection. | ||
| 40 | Identity | Ability to enforce consent-based profile data access so AI-assisted features and other portal workflows use only user-authorized fields and approved data sources. | ||
| 41 | Identity | Ability to require active MySC.gov authentication for community participation and enforce adult-only community access rules, including restrictions on direct communication between minor users and adult users. | ||
| 42 | Identity | Ability to enforce user‑controlled credential ownership, including upload, import, partner‑pushed ingestion, and selective sharing based on explicit user consent. | ||
| 43 | Security | Ability to provide privileged and administrative access controls | ||
| 44 | Security | Ability to provide published breach disclosure policy | ||
| 45 | Security | Ability to provide published screening and hiring practices for employees who access enterprise data and user information | ||
| 46 | Security | Ability to provide secure APIs supporting multi-agency integration, including role-based and token-based access, partner-level authorization, API gateway enforcement, and lifecycle management for onboarding and revocation of partner access | ||
| 47 | Security | System shall have data encrypted in transit | ||
| 48 | Security | Ability to have customer-configurable data loss prevention (DLP) | ||
| 49 | Security | Ability to have application layer vulnerability scans permitted/conducted/reported | ||
| 50 | Security | Ability to have multitenant controls for separation of users and data within the service | ||
| 51 | Security | Ability to have access control support on files and content | ||
| 52 | Security | Ability to have proactive auditing and notification on incidents of inappropriate management activity | ||
| 53 | Security | Ability to have permitted "right to audit" (vulnerability scan) or vendor supplied 3rd party assessment | ||
| 54 | Security | Vendor to supply high level results of regular penetration tests | ||
| 55 | Security | Ability to have documented intrusion prevention and detection capabilities | ||
| 56 | Security | Ability to provide documented distributed denial of service (DDoS) prevention capabilities | ||
| 57 | Security | Vendor shows services align to Cloud Security Alliance (CSA) framework as well as certifications, if any | ||
| 58 | Security | Ability to have configurable content hygiene (for example, antivirus and anti-spam [AV/AS]) | ||
| 59 | Security | Ability to run network penetration tests against the service, or arrange for independent third parties to conduct periodic network penetration tests and report the results | ||
| 60 | Security | Ability to have, in case of breach or compromise of data or users, appropriate notification timelines of the proposed Find Your Future Portal solution impact based on severity, and third-party investigation support | ||
| 61 | Security | Ability to have PCI compliance | ||
| 62 | Security | System shall test for, and mitigate, OWASP top 10 risks | ||
| 63 | Security | Ability to configure and enforce strong/complex passwords for customer and provide support for Multi-factor authentication | ||
| 64 | Security | Ability to mask any data element based upon configurable rules and elements including Name, Address, etc. | ||
| 65 | Security | Ability to have advanced anti-fraud features (detecting and alerting) - suspicious connections and suspicious account activity | ||
| 66 | Security | Ability to produce real-time reports detailing end-to-end data flows across portal and partner systems, including visibility into data origin, destination, usage, and cross-agency data exchange patterns | ||
| 67 | Security | Ability to respond to, capture, and erase personal data according to data subject rights request | ||
| 68 | Security | Ability to support 'passport' single sign-on capabilities, seamlessly authenticating users into external partner agency applications without requiring duplicate credential entry | ||
| 69 | Security | Ability to link the user logon ID to citizen profiles, state identification numbers, or partner agency account profiles to maintain a 360-degree view of the customer. | ||
| 70 | Security | Ability to have immutable backups | ||
| 71 | Security | Ability to provide independent third party assessment (SOC 2 or ISO27001 Certification or equivalent) | ||
| 72 | Security | Ability to suspend or revoke user/API access in real time | ||
| 73 | Security | Ability to provide published hardware disposal/destruction policy (e.g., hard drives, backups, data storage media) | ||
| 74 | Security | Ability to log and audit direct (e.g., administrative, DBA) access to the data store and related high-privilege administration functions, regardless of access method and forward to third-party reviewer (SOX compliance) | ||
| 75 | Security | Ability to enforce closed-loop AI controls so AI-assisted features cannot independently store, alter, submit, transmit, or share user information without user confirmation, system authorization, and applicable policy controls. | ||
| 76 | Security | Ability to prevent AI-assisted features from accessing, modifying, generating, storing, or transmitting authentication credentials, identity attributes, or security tokens. | ||
| 77 | Security | Ability to enforce field-level data-use restrictions that exclude AI workflows from any data sets or fields prohibited by Data Use Agreements, law, policy, or State configuration. | ||
| 78 | Security | Ability to ensure that analytics identifiers are non identifiable, non reversible, and cannot be linked to authentication credentials, identity attributes, or security tokens. The system shall prevent any workflow from re identifying a user through analytics identifiers. | ||
| 79 | Security | Ability to protect externally accessed volatile session-based data from unauthorized storage, replication, caching, logging, reuse, disclosure, or downstream transmission outside the authorized workflow. | ||
| 80 | Security | Ability to enforce community and mentorship privacy controls including profile visibility rules, user blocking and reporting, message retention policies, notification controls, and secure handling of moderation logs and appeal records. | ||
| 81 | Security | Ability to enforce youth-protection and age-gating controls across portal components, including adult community restrictions, parent/guardian facilitation where required, and data minimization for minors. | ||
| 82 | Security | Ability to protect API credentials, OAuth tokens, identity-provider tokens, job-board credentials, and other integration secrets from cleartext storage or unauthorized access. | ||
| 83 | Security | Ability to prohibit password collection, unauthorized scraping, unofficial access methods, or posting methods prohibited by a third-party provider, destination site, or State-approved agreement. | ||
| 84 | Security | Ability to enforce verification, provenance tracking, and consent‑driven authorization for credentials ingested from external credential providers. | ||
| 85 | Security | Ability to secure all Digital Wallet data using encryption at rest, encryption in transit, role‑based access controls, consent‑driven sharing, and prevention of unauthorized caching or replication. |
Network
| Software Technical Requirements | ||||
| Network | ||||
| # | Sub-Process / Topic | Requirement | Requirement Met? (Fully Met, or Not Met) | Comments |
| 1 | Network | System shall support average + std. deviation + % of requests above defined maximum or SLA of performance and latency of the service are tested and published annually | ||
| 2 | Network | Ability to provide real-time performance network monitoring service | ||
| 3 | Network - Security | Vendor shall have partnership(s) with cloud security gateway or cloud access security broker(s) | ||
| 4 | Network - Security | Ability to provide documented firewall considerations and required configurations. Including restrictions on who is able to access the service, limits on types of traffic, and traffic inspection | ||
| 5 | Network - Security | Ability to deploy a Web Application Firewall with SSL/TLS offloading to decrypt and inspect encrypted traffic for hidden threats and mitigate OWASP Top 10 risks. | ||
| 6 | Network - Security | Ability to provide 24x7x365 network security monitoring with intrusion detection/prevention, bot mitigation, and Distributed Denial of Service protections. | ||
| 7 | Network - Capacity | Ability to leverage content delivery networks (CDN) and edge caching to support high-volume, geographically distributed public access | ||
| 8 | Network - Capacity | Ability to provide a network sizing tool (bandwidth, latency, etc.) for remote locations based on user counts, business functions, etc. | ||
| 9 | Network-Security | Ability to track user/system access at firewall | ||
| 10 | Network | Ability to whitelist and configure user/system access without network engineering (via admin console), at least for commonplace scenarios. Ability to export these rules | ||
| 11 | Network | Ability to support low bandwidth and high-latency environments with a mobile-first architecture suitable for statewide public access, including rural and underserved populations | ||
| 12 | Network | Architecture minimizes excessive cross-system API calls and “chattiness” when interacting with multiple partner applications, ensuring performant user experience across distributed systems | ||
| 13 | Network | Ability to segment and or microsegment enterprise data to meet zero trust requirements | ||
| 14 | Network | Ability to support secure API-only access patterns for approved mobile application and desktop applet interactions while prohibiting direct local storage of sensitive data. | ||
| 15 | Network | Ability to securely manage notification token lifecycle controls for mobile and applet interactions, including issuance, storage, renewal, and revocation. |
System Admin-Mgmt
| Software Technical Requirements | ||||
| Application Administration | ||||
| # | Sub-Process / Topic | Requirement | Requirement Met? (Fully Met, or Not Met) | Comments |
| 1 | Administration | Web-based management consoles supporting both central administration and delegated administration across multiple partner agencies and organizations | ||
| 2 | Administration | System shall have single-console management of cloud services | ||
| 3 | Administration | System shall have usage and data tracking tools | ||
| 4 | Administration | Ability to bulk export and import users and permissions | ||
| 5 | Administration | System shall support defined real-time thresholds and alerts | ||
| 6 | Administration | System shall have customer-defined real-time thresholds and alerts | ||
| 7 | Administration | System shall have change management logging with six or more months of history | ||
| 8 | Administration | Ability to provide extensibility via scripting without impacting ability to upgrade | ||
| 9 | Administration | Ability to create masked or synthetic datasets for testing purposes, avoiding replication of sensitive cross-agency production data | ||
| 10 | Administration | Ability to manage backups and recovery strategies for portal-managed data, while supporting integration with external systems that maintain their own independent backup and recovery processes | ||
| 11 | Administration | Ability to have training, development, test/QA, and production environments | ||
| 12 | Administration | Ability to provide and maintain a production-representative non-production environment that may be used by the State for development, testing, quality assurance, integration testing, user acceptance testing (UAT), training, release validation, demonstrations, and operational readiness activities without impacting the production environment. | ||
| 13 | Administration | Ability to add or remove non-production environments with minimal notice/duration and no production outage | ||
| 14 | Administration | Ability to move code, configuration and/or data between environments (scheduled and unscheduled) | ||
| 15 | Administration | Ability to schedule regular data refreshes from production to a non-production clone environment. Non-production environments shall be maintained in a production-representative state. The Vendor shall establish and document procedures for synchronizing application versions, configurations, integrations, security settings, workflows, reference data, and other relevant components in order to minimize environment drift and ensure testing, training, and release validation activities accurately represent the production environment. Any approved differences between production and non-production environments shall be documented and disclosed to the State. | ||
| 16 | Administration | Ability to maintain at least one production-representative non-production environment that mirrors the production environment to the maximum extent practicable and supports validation of releases, patches, upgrades, integrations, security updates, configuration changes, and other significant system modifications prior to deployment to production. | ||
| 17 | Administration | Ability to orchestrate workflows and dependencies across multiple partner systems and integration points, including API and event-driven processes | ||
| 18 | Administration | Ability to bring system up in a restricted mode for administrative-only access | ||
| 19 | Administration | Ability to use CCWD FYF ITSM system for incident, problem, change and configuration management | ||
| 20 | Administration | Ability to manage, reconfigure, change or otherwise alter integration points as part of scheduled production -> non-production data refresh | ||
| 21 | Administration | Ability to detect and manage partner system outages and provide graceful degradation of portal functionality. Ability to notify users of partial service disruptions tied to specific partner systems | ||
| 22 | Administration | Ability to provide no-code or low-code administrative configuration of guided intake logic, eligibility routing, approval workflows, pathway-building workflows, and user assistance workflows. | ||
| 23 | Administration | Ability to configure staff roles, permissions, supervisory access, confidentiality restrictions, program boundaries, regional boundaries, and assignment rules for counselors, navigators, advisors, case managers, and related support staff. | ||
| 24 | Administration | Ability for State administrators to manage community categories, participation rules, conduct rules, automated moderation criteria, appeal workflows, and mentor/mentee availability controls. | ||
| 25 | Administration | Ability for State administrators to configure employer job posting destinations, destination-specific required fields, approval workflows, posting status workflows, expiration rules, withdrawal rules, correction workflows, and resubmission workflows. | ||
| 26 | Administration | Ability to maintain and administer a technical registry of active Memoranda of Understanding and Data Use Agreements governing data sharing, data-use restrictions, retention, and consent requirements. | ||
| 27 | Administration | Ability to configure State-approved AI guardrails, approved workflows, approved data sources, allowed AI actions, business rules, labeling requirements, and human-review rules without custom code where feasible. | ||
| 28 | Administration | Ability to configure data refresh cadence, age limits, revalidation rules, and agency administrator review workflows for program, service, opportunity, and resource information housed or displayed in the portal. | ||
| 29 | Business Continuity and Disaster Recovery | Ability to provide business continuity across a distributed ecosystem, including handling dependencies on partner systems, degraded modes when external systems are unavailable, and maintaining portal availability independently | ||
| 30 | Business Continuity and Disaster Recovery | Ability to restore transactions from the database transaction log | ||
| 31 | Business Continuity and Disaster Recovery | System shall have software crash tolerance (i.e., server and FYF System software shall maintain its integrity in case of power failures and abrupt shutdowns) | ||
| 32 | Business Continuity and Disaster Recovery | System shall have redundancy in the application server tier | ||
| 33 | Business Continuity and Disaster Recovery | System shall have redundancy in the database server tier | ||
| 34 | Business Continuity and Disaster Recovery | System shall have restart and recovery capability after system failure with no loss of data or software components | ||
| 35 | Business Continuity and Disaster Recovery | System shall have roll-back capability of data (e.g., corruption, invalid data) | ||
| 36 | Business Continuity and Disaster Recovery | System shall have roll-back capability of software / system updates | ||
| 37 | Business Continuity and Disaster Recovery | System shall have integrity checking capability to identify the existence of program and/or system discrepancies and issue an alert to the appropriate systems operations team | ||
| 38 | Business Continuity and Disaster Recovery | System shall have file protection capability to limit the types of operations (e.g. read, write, delete, data dictionary modification) that can be performed by individual users on given data or program files | ||
| 39 | Business Continuity and Disaster Recovery | System shall have incremental, differential, and full backups and restores of the database, core and customized software, software and database configuration options, and user preferences and rights | ||
| 40 | Business Continuity and Disaster Recovery | Ability to bring system up within a predefined RTO time with a data loss not to exceed a predefined RPO in a remote location in the event of a disaster | ||
| 41 | Business Continuity and Disaster Recovery | Ability to perform regular (example: annual) disaster recovery tests without interference or risk to production environment | ||
| 42 | Business Continuity and Disaster Recovery | Ability to restore and roll forward immutable backups at DR location | ||
| 43 | Business Continuity and Disaster Recovery | Ability to return to production site at the end of a disaster and restore DR capability | ||
| 44 | Business Continuity and Disaster Recovery | Ability to perform backups and all other administrative functions at DR location | ||
| 45 | System Capacity & Performance | Ability to track and log system uptime and transaction response times in order to provide information for SLA monitoring | ||
| 46 | System Capacity & Performance | Ability to the meet SLAs during the Deployment and Go-Live Support Phase | ||
| 47 | System Capacity & Performance | Ability to integrate system alerts into CCWD FYF ITSM system | ||
| 48 | System Capacity & Performance | Ability to monitor and report system performance for personalized pathway, community, mentorship, AI-assisted, mobile, applet, and multi-board posting workflows without degradation of the core portal experience. |
Storage
| Software Technical Requirements | ||||
| Storage | ||||
| # | Sub-Process / Topic | Requirement | Requirement Met? (Fully Met, or Not Met) | Comments |
| 1 | Storage | Ability to provide documented high-availability and disaster recovery capabilities and procedures | ||
| 2 | Storage | Ability to support data ingestion and export via APIs, ETL pipelines, and integration with enterprise data platforms (e.g., Data Lake), including structured and unstructured data | ||
| 3 | Storage | Ability to enforce data deletion and retention policies across both portal-managed data and, where applicable, propagate deletion requests to partner systems based on data-sharing agreements | ||
| 4 | Storage | Ability to provide storage limits defined and reasonable per service, group, and user | ||
| 5 | Storage | Ability to surpass service storage limits without impacting service delivery | ||
| 6 | Storage | Ability to publish/provide locations of data centers storing data | ||
| 7 | Storage | Ability to accommodate Enterprise dictating data locale residency | ||
| 8 | Storage | Ability to provide archive/e-discovery as a service offering | ||
| 9 | Storage | System shall have real-time data layer performance monitoring service providing metrics (e.g., database, any data serving components such as MQ). This consists of both "Storage" and "Database/Data Access" | ||
| 10 | Storage | System shall have data replication services that are database-aware, and maintain transactional integrity | ||
| 11 | Storage | Ability to perform flash copies of production and non-production systems | ||
| 12 | Storage | Ability to make storage changes (add, move, rebalance, remove, etc.) without a system outage | ||
| 13 | Storage | Ability to store only information entered directly by the user into the proposed FYF Portal profile unless storage is expressly authorized by applicable data-sharing agreement, user consent, policy, or legal requirement. | ||
| 14 | Storage | Ability to access and display approved external or internal system information as volatile session-based data when authorized, without permanently storing that external data unless expressly permitted. | ||
| 15 | Storage | Ability to clearly distinguish between information saved in the user’s FYF Portal solution profile and information temporarily accessed from other systems during a session or authorized transaction. | ||
| 16 | Storage | Ability to generate and maintain a non identifiable, pseudonymous analytics identifier for each user that supports analytics, reporting, and longitudinal trend analysis without storing or exposing personal identity attributes. | ||
| 17 | Storage | Ability to prevent unauthorized persistence, replication, caching, logging, reuse, downstream storage, or disclosure of externally accessed data unless expressly permitted by the applicable authority. | ||
| 18 | Storage | Ability to store AI-assisted interaction metadata, including opt-in status, generated draft content, user edits, rejections, regenerations, final user-approved submissions, provenance labels, and approval status. | ||
| 19 | Storage | Ability to define and enforce retention and purge rules for AI-generated drafts, community content, moderation logs, experiential learning applications, referral data, and user-submitted documents. | ||
| 20 | Storage | Ability to maintain lineage and retention rules for community posts, messages, moderation actions, flagged content, and appeal decisions. | ||
| 21 | Storage | Ability to support multiple data repositories and leverage State-approved enterprise data platforms, including the DEW Azure Data Lake where appropriate, for large-scale historical, longitudinal, or Gold Data Model analytics. | ||
| 22 | Storage | Ability to ensure all data collected, processed, or stored by the system resides within the Continental United States. |
App Arch-Integration
| Software Technical Requirements | ||||
| Architecture and Integration | ||||
| # | Sub-Process / Topic | Requirement | Requirement Met? (Fully Met, or Not Met) | Comments |
| 1 | Application Architecture | Solution shall be designed as a modular, cloud-based orchestration platform that serves as a unified experience layer integrating data and services from multiple external partner systems | ||
| 2 | Application Architecture | The solution shall allow users to enter information as a guest without creating an account and receive a personalized pathway based on the information provided. Guest pathway generation shall operate entirely within the portal’s stateless session model and shall not persist any data. | ||
| 3 | Application Architecture | Ability to implement a Case Management Interoperability Framework that normalizes intake data, service‑plan elements, referral statuses, appointment information, milestone tracking, and case‑note metadata into a consistent State‑approved schema only for cases where the user has been positively matched and authorized access has been confirmed by the case‑management system owner. | ||
| 4 | Application Architecture | Ability to support bi‑directional exchange of approved case‑management information with SCWOS and other State‑approved systems using APIs, secure file transfer, or other approved integration patterns. | ||
| 5 | Application Architecture | Ability to enforce role‑based access, consent rules, and data‑sharing agreements when retrieving, displaying, or routing case‑management information across partner systems. | ||
| 6 | Application Architecture | Ability to support interoperable referral workflows, warm hand‑off tracking, appointment scheduling, appointment status exchange, and service‑coordination workflows across SCWOS and other State‑approved systems. | ||
| 7 | Application Architecture | Ability to retrieve approved case‑note metadata from partner systems and route authorized updates back to those systems without storing protected case‑note content unless expressly permitted by consent, policy, or data‑sharing agreement. | ||
| 8 | Application Architecture | Ability to retrieve and display approved case‑management data elements for a matched user, including appointments, referrals, tasks, milestones, case‑plan elements, program enrollment status, and case status, as volatile session‑based data. | ||
| 9 | Application Architecture | Ability to retrieve and display case‑note metadata for a matched user without retrieving or displaying protected case‑note content. | ||
| 10 | Application Architecture | Ability to integrate with partner systems using a tiered model including (1) federated single sign-on (“passport”), (2) API-based integration for real-time data exchange, and (3) SFTP-based integration for legacy systems where required | ||
| 11 | Application Architecture | Ability to establish connectivity with application and data structure types via a variety of Transports, such as Rest over HTTPS, MQ, direct DB connection/ODBC/JDBC, etc. | ||
| 12 | Application Architecture | System shall have platform-initiated events and notifications | ||
| 13 | Application Architecture | Ability to support the capability for data extraction, encryption and transmission (ODBC, xml, web services, flat files, PDF documents, etc.) | ||
| 14 | Application Architecture | The solution shall allow guest users to export a pathway as a static document through user initiated actions including PDF generation, printing, emailing, or texting. Exported pathways shall not be stored as persistent data unless the user explicitly saves the exported file in their document vault after creating an account. | ||
| 15 | Application Architecture | The solution shall allow authenticated users to export a pathway as a static document through user initiated actions including PDF generation, printing, emailing, or texting. Exported pathways shall not be stored as persistent data unless the user explicitly saves the exported file in their document vault. | ||
| 16 | Application Architecture | Specify browsers and minimum versions supported. Must support mobile/tablet specific scenarios such as Safari | ||
| 17 | Application Architecture | Ability to automate the deployment of software and updates to user workstations and mobile devices including, but not limited to web-based deployment tools | ||
| 18 | Application Architecture | Ability to automatically detect and resolve user workstation and mobile device application version incompatibilities with server applications | ||
| 19 | Application Architecture | Ability to provide built-in application and system configuration tables accessible by all modules | ||
| 20 | Application Architecture | Ability to provide customizable user portals including, but not limited to the ability to customize menus and forms, by user | ||
| 21 | Application Architecture | The solution shall allow users to save multiple personalized pathways by storing only the user entered information, parameters, and metadata used to generate each pathway. Metadata shall include, at a minimum, the data source, as of timestamp, and pathway generation settings. The solution shall not store API delivered or session based data when saving pathway parameters. | ||
| 22 | Application Architecture | The solution shall regenerate and redisplay a saved pathway by using the stored parameters and metadata. | ||
| 23 | Application Architecture | Ability to manage automatic job scheduling (e.g., batch data syncs, ETL pipelines, and SFTP data drops back to partner agencies) | ||
| 24 | Application Architecture | Ability to define job sequences and dependencies (i.e., run job B just after job A, only run if A is successful). Configurable notification (e.g., email, SMS). Configurable duration thresholds triggering notification | ||
| 25 | Application Architecture | Ability to accommodate background (e.g. batch) jobs 24/7 concurrently with online updates | ||
| 26 | Application Architecture | Ability to drill down from a transaction view to the supporting source document or record, regardless of the module source | ||
| 27 | Application Architecture | Ability to facilitate upgrades to future operating systems, databases and other software upgrades | ||
| 28 | Application Architecture | Ability to generate process flow diagrams for system or a subset | ||
| 29 | Application Architecture | Ability to generate data flow diagrams for system or a subset | ||
| 30 | Application Architecture | Ability to distribute workload horizontally | ||
| 31 | Application Architecture | Ability to deploy into an Active/Active model | ||
| 32 | Application Architecture | Solution shall function as a centralized experience and coordination layer serving as South Carolina’s digital front door across education, workforce, support services, employers, policy leaders, agencies, and authorized partners. | ||
| 33 | Application Architecture | Ability to provide a unified, accessible, and personalized front-end user experience that routes users to appropriate services without exposing backend ecosystem fragmentation. | ||
| 34 | Application Architecture | Ability to preserve existing agency and partner systems as authoritative Systems of Record while modernizing the experience layer without requiring a rip-and-replace approach. | ||
| 35 | Application Architecture | Ability to support personalized pathway, roadmap, timeline, journey, or equivalent architectures using profile data and authorized external system data under consent and data-sharing controls. | ||
| 36 | Application Architecture | Ability to support mobile-responsive browser access as a core portal capability and separately support full mobile application and lightweight desktop applet capabilities when approved by the State. | ||
| 37 | Integration | Ability to deploy updates through an automation pipeline, e.g., Jenkins | ||
| 38 | Integration | Ability to integrate with partner systems using a tiered model including (1) federated single sign-on (“passport”), (2) API-based data exchange, and (3) SFTP-based fallback processes where modern integration is not available | ||
| 39 | Integration | Ability to exchange information securely with external SaaS and partner systems using standards-based APIs while maintaining loose coupling between systems | ||
| 40 | Integration | Ability to exchange information and support services with external on premise solutions | ||
| 41 | Integration | Ability to integrate workflow capabilities with the proposed Find Your Future Portal solution’s inbound and outbound interfaces. | ||
| 42 | Integration | Ability to set up appropriate approval, audit trail, and reconciliation procedures for all inbound and outbound interfaces | ||
| 43 | Integration | Ability to provide API onboarding kits for partner organizations, including documentation, testing environments, and certification processes | ||
| 44 | Integration | Ability to support federated data governance and integration with enterprise data platforms while maintaining data ownership within partner systems | ||
| 45 | Integration | System shall have data access APIs (including support for BI tooling integration/connectivity) | ||
| 46 | Integration | Ability to support business function APIs | ||
| 47 | Integration | Ability to support operational APIs | ||
| 48 | Integration | Ability to support bulk import/export API | ||
| 49 | Integration | Ability to support messaging-based APIs | ||
| 50 | Integration | Ability to create a mocking service to test the API contract | ||
| 51 | Integration | Ability to support integration onboarding for diverse partner systems, including low-code, API-based, and file-based integration approaches | ||
| 52 | Integration | Ability to support modern API standards (REST, JSON, event-driven architectures) while maintaining compatibility with legacy integration formats where required | ||
| 53 | Integration | Embedded integration platform (Provide/Consumer API's) | ||
| 54 | Integration | Ability to set up appropriate approval, audit trail, and reconciliation procedures for all inbound and outbound interfaces | ||
| 55 | Integration | Ability to provide marketplace for extensions and preconfigured integrations | ||
| 56 | Integration | Ability to support integration with third-party integration (e.g. MuleSoft) solutions for both pull, push transactions | ||
| 57 | Integration | Ability to integrate with cloud services providers (e.g., Azure, AWS) | ||
| 58 | Integration | Ability to Integrate with API Management systems with the industry standard security practices (ex. OIDC, OAUTH, SAML2) | ||
| 59 | Integration | Must support Duplicate Data Detection for the Inbound data feeds | ||
| 60 | Integration | Ability to provide support for Sequential/Concurrent/Parallel processing | ||
| 61 | Integration | Ability to provide support for configurable call retry, queuing, failure notification either internally or via third-party layer, for outbound APIs | ||
| 62 | Integration | Ability to provide support for field configuration and security of IoT, telematics, or other remote API data sources, for inbound APIs | ||
| 63 | Integration | Ability to provide end-to-end traceability of transactions across portal and partner systems, including API logs, correlation IDs, and cross-system monitoring | ||
| 64 | Integration | Ability to customize error responses (similar to Usability request, but referring to API responses) | ||
| 65 | Integration | Ability to implement a multi-path integration strategy using real-time APIs for modern systems and secure data-exchange workarounds such as SFTP, batch feeds, scheduled syncs, or middleware for legacy systems. | ||
| 66 | Integration | Ability to provide integration monitoring, error handling, retry logic, exception queues, reconciliation processes, interface status reporting, and operational reporting for State-approved interfaces and data exchanges. | ||
| 67 | Integration | Ability to include all activities necessary to establish, configure, test, secure, document, monitor, maintain, troubleshoot, and operate State-approved integrations and partner or source-system connections. | ||
| 68 | Integration | Ability to support an unlimited number and type of State-approved integrations, APIs, interfaces, data feeds, link-outs, embedded handoffs, identity connections, partner connections, and source-system connections without product-tier or connector limits. | ||
| 69 | Integration | Ability to support connectivity with existing and future State-approved agencies, partners, providers, employers, education entities, workforce entities, systems of record, and third-party sources through approved integration patterns. | ||
| 70 | Integration | Ability to support job board and external posting channel integrations needed to route, submit, publish, update, close, reconcile, and report employer job postings across approved job boards, workforce systems, chamber sites, economic-development sites, and third-party posting channels. | ||
| 71 | Integration | Ability to support destination-specific data mapping, required-field validation, posting previews, employer verification checks, partner-specific requirements, rate limits, error handling, rejection tracking, status reconciliation, duplicate detection, and audit logging for job posting distribution. | ||
| 72 | Integration | Ability to preserve the authoritative status and audit history of the original portal job posting while supporting downstream publication, updates, closures, and reporting across approved posting destinations. | ||
| 73 | Integration | Ability to maintain the relationship between a single portal job posting, each associated posting location, and each posting destination for audit, analytics, reporting, operational support, partner reconciliation, and integration purposes. | ||
| 74 | Integration | Ability to support third-party profile integrations using approved OAuth/OpenID Connect authentication, selective field import, user preview/edit controls, token protection, user disconnect capability, and prohibition on password collection or unofficial access methods. | ||
| 75 | Integration | Ability to support secure data exchange for community participation, moderation events, flagged content, appeal workflows, and age-verification processes while enforcing youth-protection and role-based permissions. | ||
| 76 | Integration | Ability to support addition of State-approved partners, source systems, API endpoints, feeds, interfaces, link-outs, embedded handoffs, identity connections, and other approved connections after award or during operations without additional charge when the connection is required to implement, activate, operate, maintain, or sustain functionality already included in an awarded CLIN. Separately priced additional integrations are permitted only when expressly allowed under Section L.5.6.2 and accepted by the State. | ||
| 77 | Integration | Requirement: Ability to ingest credentials from partner systems using APIs, secure file transfer, batch synchronization, or other approved integration patterns. | ||
| 78 | Integration | Ability to ingest credentials from third‑party credentialing platforms using secure APIs, token‑based authentication, and standards‑based integration patterns without requiring the State to name or pre‑select specific credential providers. |
App Dev-Config
| Technical Requirements | ||||
| Application Development and Configuration | ||||
| # | Sub-Process / Topic | Requirement | Requirement Met? (Fully Met, or Not Met) | Comments |
| 1 | Application Development/Configuration | Ability to support a hosted development environment (e.g., Platform as a Service - PaaS) to develop, test, and deploy integrations and extensions to the portal platform and its connected partner systems ecosystem, ensuring compatibility across all integration layers | ||
| 2 | Application Development/Configuration | Ability to support a unified data architecture for portal-managed analytical data and federated data accessed from partner systems, including ingestion, visualization, and governance across the ecosystem | ||
| 3 | Application Development/Configuration | Ability to support a unified configuration management model across portal components and integrated partner systems, including version control, governance, and deployment processes | ||
| 4 | Application Development/Configuration | Ability to provide a consistent user experience across the portal and all integrated partner systems, including shared usability standards and coordinated branding | ||
| 5 | Application Development/Configuration | Ability to support real-time interaction and data exchange between portal components and external partner systems using APIs and federated identity, without requiring centralized storage of all transactional data | ||
| 6 | Application Development/Configuration | Ability to orchestrate workflows across multiple agencies and systems, including intake, eligibility determination, application processing, approvals, and cross-agency referrals | ||
| 7 | Application Development/Configuration | Ability to provide best practice workflow templates | ||
| 8 | Application Development/Configuration | Ability to provide software development kits (SDKs) including command line interfaces (CLIs) and wrappers for programmatic interfaces | ||
| 9 | Application Development/Configuration | Ability to support extensibility via scripting. Provide a list of open source or proprietary scripting languages that are supported | ||
| 10 | Application Development/Configuration | Ability to support vendor provided Professional developers program (e.g., training) | ||
| 11 | Application Development/Configuration | Ability to configure workflow rules including notifications, escalation paths, approval routing, and delegation across integrated partner systems | ||
| 12 | Application Development/Configuration | Ability to automate approval notifications | ||
| 13 | Application Development/Configuration | Ability to designate multiple approvers for a particular workflow step | ||
| 14 | Application Development/Configuration | Ability to provide configurable workflow alerts and escalation capabilities | ||
| 15 | Application Development/Configuration | Ability to incorporate "checklists" into the workflow process based on the transaction type and/or business process (e.g. on-boarding), including status notifications | ||
| 16 | Application Development/Configuration | Ability to perform internal real-time message routing to broadcast information to a user-defined group of users | ||
| 17 | Application Development/Configuration | Ability to track documents submitted for approval and review including, but not limited to a time/date stamp and user identification | ||
| 18 | Application Development/Configuration | Ability to provide documented development, source control, test, deploy process and tools to develop custom extensions (screens, reports, etc.). Approved training sequence for these activities | ||
| 19 | Application Development/Configuration | Ability to optionally modify user-facing labeling (screen field labels, report field names, etc.) for off-the-shelf entity attributes to use custom wording, tooltip, help, etc. (as applicable) | ||
| 20 | Application Development/Configuration | Ability to support concurrent enhancement development (ability to merge and deconflict independently developed modifications if necessary). Ability to deploy and roll back per-module | ||
| 21 | Application Development/Configuration | Ability to support web-based and local IDE development of modifications (local IDE offering greater functionality and/or a degree of "off-line" development capability) | ||
| 22 | Application Development/Configuration | Ability to provide CI/CD process support during development, testing | ||
| 23 | Application Development/Configuration | Ability to provide body of existing automated regression tests for core system. Ability to add custom regression test suites and tests and run on-demand or automated. Reporting capability for automated tests (e.g., success, logs, duration, coverage) | ||
| 24 | Application Development/Configuration | Ability to support easily created, modified, and grouping of unit tests (logic-based) and user-interaction (functional) tests. Ability to easily incorporate these into CI/CD | ||
| 25 | Application Development/Configuration | Ability to provide documented customization 'hooks' and customizable event callouts/"user exits" allow customization of core processes. Allow access to internal API (curated by vendor) to reuse core functionality within these extensions. Describe the extent and granularity of such customization hooks (in the "Comments" column) | ||
| 26 | Application Development/Configuration | Ability to provide generation of, access to system event logs and execution logs, searchable to user, date/time range, type of action, etc. Standardized logging framework available for custom development activity | ||
| 27 | Application Development/Configuration | Ability to control development roles with appropriate security (develop, test, deploy to environments, etc.) to support SOD compliance | ||
| 28 | Application Development/Configuration | Ability to develop a personalized pathway, roadmap, timeline, journey, or similar user experience showing current status, goals, milestones, recommended next steps, resources, and progress over time. | ||
| 29 | Application Development/Configuration | Ability to present pathway recommendations based on user-entered profile information and, where authorized, relevant information accessed from approved external or internal systems. | ||
| 30 | Application Development/Configuration | Ability to explain why a recommended pathway step is relevant, what it may cost, where it is offered, how long it may take, what requirements must be met, and what supports may be available. | ||
| 31 | Application Development/Configuration | Ability to update a user’s pathway as education, training, employment, or support-service milestones are completed and present additional recommended next steps. | ||
| 32 | Application Development/Configuration | Ability to support parent and guardian workflows, including review, confirmation, submission, approval, decline, document upload/reuse, notifications, communications, and service coordination tasks where authorized. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .