Attachment C.docx

Scope and Requirements C.1. Scope The scope of the FYF Portal project requires the Contractor to configure, integrate, test, transition, and provide ongoing sustainment for a secure solution. Functioning as a centralized Experience and Coordination Layer, the Portal will serve as South Carolina’s digital front door, providing a unified, user-friendly experience for diverse user personas, including students, job seekers, parents and guardians, counselors, navigators, advisors, case managers, veterans, employers, educators and administrators, policy leaders, State agencies, and other authorized partner users.

The Contractor is responsible for the complete implementation lifecycle. This includes building a personalized user experience layer; establishing an Identity and Security layer with Single Sign-On (SSO) through MySC.gov and other SSO options, such as ID.me and Login.gov; supporting standards-based protocols including SAML 2.0, OAuth 2.0, and OpenID Connect; providing secure alternative authentication methods for users who do not use SSO; and creating a federated Data and Analytics architecture to support cross-agency dashboards. The Contractor shall establish, maintain, and support appropriate non-production environments throughout the contract lifecycle, including environments used for development, testing, quality assurance, integration testing, user acceptance testing, training, staging, release validation, and operational readiness activities. Such environments shall be maintained in a production-representative state to support accurate testing, training, deployment readiness, and release management.

The FYF Portal is intended to provide a user-centered, personalized experience that helps individuals understand where they are today, identify meaningful goals, and navigate recommended next steps toward education, training, employment, career advancement, and long-term self-sufficiency.

The Portal should support a personalized pathway, roadmap, or journey-style experience that allows users to view their current status, goals, milestones, recommended next steps, available resources, and progress over time. The pathway should be based on information entered by the user into the FYF Portal profile and, where authorized, relevant information accessed from approved external or internal systems in accordance with applicable user authorization, consent requirements, policy, law, and data-sharing agreements.

The solicitation does not prescribe a specific visual design, layout, terminology, artificial intelligence model, or user-interface approach. The Offerors shall propose its recommended design and technical approach, provided the proposed solution demonstrates how users can clearly understand their current position, recommended next steps, available supports, progress toward their goals, and future opportunities in an intuitive, accessible, secure, controlled, and user-friendly manner.

C. 1.1 Visual and User Experience Evidence.

While the State does not prescribe a specific visual design, layout, terminology, artificial intelligence model, or user-interface approach, the Contractor must provide representative visual artifacts sufficient for the State to evaluate how the proposed solution will function and appear for the FYF Portal’s priority user journeys. At a minimum, the Contractor shall provide screen mockups, wireframes, clickable prototypes, product screenshots, or equivalent visual artifacts showing the public landing experience; career, job, and training search; career details; training and program details; graphical pathway or roadmap view; structured pathway or checklist view; employer job posting workflow; saved pathway and dashboard experience; referral or handoff tracking view; and role-based dashboard views. These artifacts must demonstrate mobile responsiveness, accessibility, plain-language presentation, consistent navigation, and how the same underlying pathway data is reflected across graphical and structured views without duplicate data entry.

One intent of the FYF Portal is to modernize the user experience while preserving the autonomy of participating South Carolina partners and allowing partners, where appropriate, to retain their existing systems and pursue modernization efforts over time. This will not be a rip-and-replace effort, meaning the State’s existing backend systems will remain the authoritative Systems of Record. To support interoperability, the Contractor must execute a multi-path integration strategy that uses real-time APIs for modern agency applications and secure data-exchange approaches, such as secure file transfers or scheduled synchronization, for legacy systems.

The Contractor’s solution and operations must strictly adhere to the South Carolina DIS-200 and DIS-210 security framework; applicable federal and State data privacy laws, including FERPA and HIPAA where applicable; Section 508 and WCAG 2.0 Level AA accessibility standards; and any other standards or regulatory requirements identified in this solicitation.

The Contractor shall implement a Case Management Interoperability Framework that enables the FYF Portal to act as a pass‑through, relay, or interpreter between multiple case‑management systems used across South Carolina. This framework must normalize intake data, service‑plan elements, referral statuses, case‑note metadata, and milestone tracking 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. The Contractor shall support bi‑directional exchange with SCWOS and other State‑approved case‑management systems using APIs, secure file transfer, or other approved integration patterns. This capability shall not override or bypass any partner system’s control over case‑management data or access permissions. All case‑management data displayed in the FYF Portal shall be accessed and presented as volatile, session‑based data, consistent with the portal’s stateless integration model, and shall not be stored, cached, or persisted unless expressly authorized by the case‑management system owner, user consent, and applicable data‑sharing agreements.

C. 1.2 User Research, Co-Design, and Usability Validation The Contractor shall conduct a structured, iterative user-research, co-design, and usability-validation process to ensure that the FYF Portal is designed, configured, and implemented around the needs, circumstances, workflows, capabilities, and expected outcomes of its intended users. The Contractor shall not rely solely on prior assessments, State or agency stakeholder meetings, internal Contractor reviews, product demonstrations, or generalized industry assumptions as substitutes for direct validation with State-designated representative users.

Subject to prior State authorization and coordination through the communication and governance processes established by the Contract, the Contractor shall plan, facilitate, document, and analyze appropriate research and validation activities. Such activities may include individual or group interviews, facilitated workshops, focus groups, contextual inquiry, workflow observations, process walkthroughs, persona and journey validation, co-design sessions, surveys, concept and prototype reviews, task-based usability testing, accessibility and assistive-technology testing, and plain-language or content-comprehension testing.

Before conducting user-research or usability-validation activities, the Contractor shall submit a User Research and Usability Validation Plan for State review and written approval. The plan shall identify the research questions and decisions to be informed; applicable user populations and workflows; proposed methods; participant-selection and recruitment criteria; accessibility and language accommodations; consent, privacy, recording, data-handling, and retention controls; schedule and relationship to design, build, testing, and release milestones; responsible personnel; required State and partner support; expected deliverables; and methods for analyzing, documenting, and incorporating findings.

The activities shall include State-designated representatives of the user populations applicable to the functionality and user journeys included in each release. Such populations may include students, job seekers, adult learners, parents and guardians, counselors, navigators, advisors, case managers, veterans, employers, educators and administrators, State and partner-agency personnel, policy leaders, and users with disabilities or differing levels of digital literacy, language proficiency, connectivity, or access to technology.

The Contractor shall not independently recruit, contact, interview, survey, observe, record, or collect information from users or stakeholders without prior State authorization. Activities involving minors or other protected or vulnerable populations shall comply with State-approved consent, parent or guardian facilitation, youth-protection, privacy, security, accessibility, and data-handling requirements.

User research and usability validation shall be conducted iteratively throughout discovery, design, configuration, development, testing, release readiness, Hypercare, and continuous improvement, as applicable. At a minimum, representative-user validation shall occur before the State approves final priority-user journeys and before the applicable functionality is accepted for production release.

The Contractor shall document material research and validation activities, participant categories, methods, scenarios, findings, accessibility observations, usability issues, recommendations, design decisions, unresolved issues, remediation actions, and resulting changes. The Contractor shall maintain traceability from material findings to personas, user journeys, requirements, design artifacts, prototypes, backlog items, configuration decisions, test cases, defects, remediation actions, release decisions, and accepted functionality.

Material usability, accessibility, plain-language, workflow, or user-comprehension issues identified through these activities shall be corrected, incorporated into a State-approved remediation plan, or expressly accepted in writing by the State before the applicable functionality is accepted. When the Contractor does not implement a material user recommendation, the Contractor shall document the reason and obtain State review and approval of the disposition.

User research and usability validation do not replace State review, approval, testing, or acceptance. The State retains final authority over participating user populations, research activities, requirements, design decisions, release scope, remediation dispositions, and acceptance of the resulting Portal experience.

C. 1.3. Required Response Scope, Release Prioritization, and Contract Lifecycle Functionality The functionality described in this solicitation includes requirements and desired capabilities that may be implemented over multiple releases during the life of the contract. The State intends to begin implementation with an initial Minimum Viable Product, referred to as MVP Release 1, followed by Release 1.1. MVP Release 1 and Release 1.1 represent the State’s initial implementation priorities.

Not all functionality described in this solicitation is expected to be included in MVP Release 1 or Release 1.1. However, the Contractor must respond to and price all functionality described in this solicitation, regardless of whether the functionality is identified for MVP Release 1, Release 1.1, a later release, an optional module, an enhancement, or a future contract lifecycle capability.

The State may elect to implement remaining functionality at any time during the life of the contract, in whole or in part, based on the needs, priorities, funding, operational readiness, policy direction, and decisions of the State. The State also reserves the right not to implement some or all remaining functionality beyond MVP Release 1 and Release 1.1.

The Contractor shall clearly identify which functionality is included in the proposed MVP Release 1 and Release 1.1 implementation; which functionality is available as part of the proposed platform but not initially implemented; which functionality requires configuration, customization, integration, third-party services, additional licensing, or future implementation services; and which functionality is proposed as an optional or modular future enhancement.

The Offeror may price remaining functionality individually, by module, by feature cluster, by release package, or by another clearly defined pricing structure that aligns with the Contractor’s proposed platform and implementation approach. However, the pricing structure must provide sufficient detail for the State to understand the cost, dependencies, assumptions, sequencing flexibility, and implementation impact of selecting, deferring, accelerating, modifying, or declining specific functionality during the contract term.

The State places significant value on flexibility. The flexibility of the proposed solution, pricing model, implementation sequencing, modularity, scalability, configurability, and ability to support future State decisions without unnecessary rework or cost escalation will be considered as part of the evaluation.

The Contractor shall not treat functionality outside MVP Release 1 and Release 1.1 as out of scope. Such functionality remains within the required response and pricing scope of this solicitation, even if implementation is deferred, phased, optional, or subject to future State direction.

The FYF Portal shall support the State’s ability to use de‑identified, anonymized, or pseudonymized data derived from user‑entered information and from data stored in accordance with applicable consent, policy, and data‑sharing agreements. Such de‑identified data may be used for analytics, forecasting, service‑planning, continuous improvement, and other State‑approved operational or strategic purposes. De‑identified data shall not contain personal identifiers, shall not be reasonably re‑identifiable, and shall comply with all applicable privacy laws, DUAs/MOUs, and State‑approved governance rules. Use of de‑identified data does not require additional user consent and shall not override consent‑based access rules governing identifiable information.

Offerors are advised that while MVP Release 1 and Release 1.1 designations are listed in Attachment 7, Contractors must also include all associated items from Attachment 5, Technical Requirements Addendum, and document their complete release prioritization approach within Attachment 7, CCWD FYF Portal Requirements Traceability Matrix. It is the Contractor’s responsibility to identify any cross-cutting functionality needed to meet MVP Release 1 and Release 1.1 requirements and to articulate the justification for each cross-cutting requirement.

C. 1.4. Digital Wallet and Credential Registry Services The Contractor shall implement a secure, State‑approved Digital Wallet within the FYF Portal that enables users to store, manage, verify, and selectively share credentials and related artifacts in accordance with all identity, privacy, consent, and data‑sharing requirements established in this solicitation. The Digital Wallet shall operate as a core component of the Portal’s Experience and Coordination Layer and shall support credential portability across participating education, workforce, licensing, and credential‑issuing partners.

Collectively, the Digital Wallet, Credential Registry, credential verification, skills, education, training, work-experience, and interoperability capabilities required by this solicitation shall support a State-approved Learning and Employment Record (LER), meaning a portable, verifiable, machine-readable record of an individual's learning, skills and competencies, credentials, and employment or work experience that can be securely accessed, exchanged, and selectively shared across authorized education, workforce, employer, credentialing, and other participating systems.

The Digital Wallet shall allow users to upload credentials directly, import credentials from partner systems, or receive credentials pushed by authorized agencies or institutions, provided that such ingestion is governed by user consent, partner policy, and applicable DUAs/MOUs. The Contractor shall ensure that the Wallet maintains a clear distinction between credentials entered by the user, credentials imported from partner systems, and volatile session‑based data accessed from Systems of Record that may not be stored unless expressly authorized. The Contractor shall prevent unauthorized caching, replication, or retention of prohibited data.

The Digital Wallet shall support credential provenance, issuer metadata, timestamps, verification status, and State‑approved validation workflows. When authoritative verification sources exist, the Contractor shall implement mechanisms to confirm credential authenticity and reflect verification outcomes within the Wallet. The Wallet shall also support selective sharing of credentials with employers, educators, advisors, case managers, and other authorized users, subject to role‑based access controls, consent rules, and State‑approved privacy requirements.

Credential data stored in the Digital Wallet shall integrate with the FYF Portal’s personalized pathway, roadmap, and recommendation engine. The Contractor shall ensure that credential information may be used to refine pathway recommendations, support eligibility determinations, inform skills inference, and enhance military‑to‑civilian translation workflows. The Wallet shall also support user‑initiated export capabilities, including PDF, email, or text‑based sharing of credential summaries.

The Digital Wallet shall be fully accessible, mobile‑responsive, and aligned with WCAG 2.0 AA standards. It shall support multilingual access, plain‑language presentation, and intuitive credential management workflows. The Contractor shall provide a production‑representative non‑production environment for Digital Wallet testing, validation, and training, consistent with the environment requirements defined in this solicitation.

The Digital Wallet shall support ingestion of credentials from third‑party credentialing platforms, credential issuers, and credential verification services approved by the State. This ingestion capability shall allow the FYF Portal to receive, interpret, and display credentials originating from external credential providers, including but not limited to education institutions, training providers, licensing bodies, employers, military organizations, and nationally recognized credentialing services. The Contractor shall implement this capability using standards‑based integration patterns that support secure API exchange, token‑based authentication, and consent‑driven authorization. The Contractor shall ensure that credentials ingested from third‑party systems are treated in accordance with State privacy, consent, and data‑sharing requirements, including the distinction between volatile session‑based data and credential artifacts authorized for persistent storage within the Digital Wallet. The Contractor shall not require the State to name or pre‑select any specific credentialing provider and shall ensure that the ingestion framework is sufficiently flexible to support future credentialing partners without requiring architectural redesign or contract modification.

The Digital Wallet shall be delivered in Release 1.1 unless the Contractor identifies cross‑cutting dependencies requiring earlier delivery to support MVP Release 1 functionality. Any such dependencies shall be documented in Attachment 7.

The Contractor shall ensure that the Digital Wallet and Credential Registry Services are fully available in all non‑production environments, including credential ingestion, verification, provenance tracking, and sharing workflows, to support State testing, validation, training, and partner onboarding.

The Digital Wallet and Credential Registry Services shall be subject to all performance management requirements in Section C.16.1, including monitoring, alerting, reporting, and compliance with State‑approved operational thresholds. Credential ingestion, verification, and sharing shall be included in all performance dashboards and operational reporting.

C. 1.5. Release-Designation Control. Attachment 7 - CCWD FYF Portal Requirements Traceability Matrix, is the controlling release traceability instrument for MVP Release 1, Release 1.1, and future contract lifecycle functionality. Any requirement that is necessary to operate, secure, evaluate, accessibly present, govern, integrate, report, or validate an MVP Release 1 or Release 1.1 capability shall be identified as part of the applicable release, even if the requirement is cross-cutting, technical, administrative, governance-related, data-related, integration-related, security-related, privacy-related, or dependency-related rather than a user-facing feature. The Contractor shall not leave release placement ambiguous for any requirement that is necessary to deliver a proposed MVP Release 1 or Release 1.1 capability.

C. 2. Requirements The State expects that the proposed solution will be engineered using industry-leading architectural principles, planned with comprehensive project controls, implemented in accordance with industry best practices, and transitioned into production without service interruption. The requirements outlined below are intended to improve performance, reliability, and operational efficiency while supporting long-term scalability and cost-effectiveness. Because the Portal must be modular, optional or future-growth capabilities may be identified, with the understanding that such services may be exercised at the State’s discretion.

The Contractor shall test and validate releases, patches, upgrades, integrations, security updates, configuration changes, and other significant modifications within a production-representative non-production environment prior to production deployment. The State reserves the right to review and approve release validation results before implementation in the production environment.

All functional and capability requirements identified in this section must be addressed by the Contractor. Requirements identified for MVP Release 1 and Release 1.1 represent the State’s initial implementation priorities. Requirements not assigned to MVP Release 1 or Release 1.1 remain part of the required proposal response and pricing scope and may be implemented during the life of the contract at the State’s discretion. The Contractor shall use Attachment 7, CCWD FYF Portal Requirements Traceability Matrix, to identify the proposed implementation approach and release alignment for each requirement or requirement cluster. Applicable assumptions and dependencies shall be described in the technical proposal, and associated pricing shall be identified through Attachment 6 – CLIN Catalog.

In alignment with the CCWD FYF Portal Requirements Traceability Matrix (RTM), the Contractor must propose and develop the appropriate technologies, platforms, and methodologies to support the following architectural layers:

· User Experience (Integrated Portal) Layer: The Contractor must provide the technology to deliver a unified, accessible, and personalized front-end interface. This layer must route users seamlessly to the appropriate services without exposing them to backend ecosystem fragmentation and must provide consistent experiences across web and mobile endpoints.

· Integration Layer: The Contractor must develop and implement appropriate middleware, enterprise service bus (ESB), API gateway, or equivalent integration technologies to support interoperability. This includes an N-Tier architecture to safely route search and form data back to partners and to support both real-time API integrations and secure file transfers for legacy applications.

· Data and Analytics Layer: The Contractor must establish a federated master data strategy and analytics platform capable of consuming and presenting shared data consistently. This layer must support data standardization, validation, and data quality management, enabling accurate longitudinal analysis across education, workforce, and economic-development domains under consistent governance standards. The Find Your Future Portal will operate as a stateless integration layer. When a user makes a request, the portal will establish a short‑lived session that retrieves and displays information from authoritative systems of record through real‑time API calls. All API‑delivered data will be treated as temporary: the portal will read, use, and present the data only for the duration of the session, and will discard it once the session ends. Authoritative data will remain solely within the system of record; the session will provide a controlled, time‑limited window into that data. The portal will only store API‑delivered data when two conditions are met: (1) the user explicitly requests and authorizes that the session data be saved to their FYF Portal profile, and (2) the governing Data Use Agreement, Memorandum of Understanding, or partner policy permits the portal to retain that data. If either condition is not met, the portal will not persist the data. In addition to real‑time API integrations, the portal will store any data that partners intentionally provide through SFTP, other secure file‑transfer methods, or other batch‑based delivery mechanisms. These deliveries represent deliberate, agreement‑governed provisioning of data from the system of record. To ensure accuracy and timeliness, the portal will require recurring updates of all file or batch‑delivered datasets. The portal will also consume publicly available data sources, including labor market information, occupational datasets, education program listings, and other open data, to supplement user-facing analytics and pathway recommendations. All data presented to users will be tagged with its source and, when available, an “as of” date indicating when the data was last updated or retrieved. This tagging will support transparency, traceability, and clarity regarding data freshness and origin across the federated Data & Analytics architecture. The solution shall generate and use a non identifiable, pseudonymous analytics identifier for each user. This identifier shall allow the State to analyze user interactions, pathway usage, search behavior, and other approved analytics without exposing personal identity attributes. The identifier shall not be reversible to a specific individual and shall not contain or embed any personal data. The identifier shall be stored, transmitted, and used only in accordance with State approved privacy, consent, and data sharing rules. Community content, moderation actions, mentor and mentee interactions, and related metadata shall comply with State-approved data lineage, retention, privacy, and governance requirements as part of the Data and Analytics Layer.

· Identity and Security Layer: The Contractor must build the solution on a single, scalable security architecture. This layer must support federated authentication, including SSO and secure alternative authentication methods for users who do not authenticate through SSO; enforce granular role-based access; securely manage data encryption in transit and at rest; and embed privacy and consent tracking directly into the Portal experience. The Identity and Security Layer shall also govern all access to the User Community and Mentorship Function described in Area 1. This includes enforcement of age-gating, parent or guardian facilitation for minor users, youth-protection controls, role-based permissions, profile visibility rules, consent requirements, user blocking or reporting, and any State-approved safety or privacy controls applicable to community participation and mentorship interactions. AI-related identity, privacy, and consent controls must align with NIST SP 1270, the South Carolina Statewide AI Strategy, and recognized AI security and privacy best practices, including NIST AI RMF security guidance and ISO/IEC 27001/42001 principles.

The Digital Wallet and Credential Registry Services described in Section C.3.1.4 shall be treated as a cross‑cutting capability. The Contractor shall ensure that all identity, security, privacy, consent, audit, interoperability, and environment requirements described in Section C.3.2 apply fully to the Digital Wallet and all credential ingestion, verification, storage, and sharing workflows.

C. 2.1 Functionality & Capability

C. 2.1.1. Personalized Pathway / Roadmap User Experience The solution should provide a personalized pathway, roadmap, timeline, journey, or similar user experience that helps each user understand where they are today, what steps may help them move toward their stated goals, and what resources are available to support them along the way.

The portal shall support role‑based AI‑assisted content creation to include, but not be limited to, job descriptions, resumes, job‑specific resumes, and education‑related content such as training summaries, learning goals, personal statements, and scholarship or program‑application narratives. AI‑assisted content creation shall operate within defined portal workflows, comply with State‑approved privacy, consent, youth‑protection, and provenance requirements, and support user review, editing, acceptance, or rejection of AI‑generated drafts.

The pathway should be capable of presenting recommended next steps based on relevant information, including, but not limited to, the user’s current circumstances, interests, skills, education level, employment status, location, family needs, transportation needs, financial situation, career goals, prior experience, barriers to success, completed milestones, and other information relevant to the user’s journey.

Recommended pathway steps may include, but are not limited to:

· Educational or training opportunities.

· Credential, certificate, license, or degree requirements.

· Entry-level employment opportunities.

· Career advancement opportunities.

· Work experience, internship, apprenticeship, or on-the-job training opportunities.

· Supportive services and resources.

· Financial aid, tuition assistance, or other funding options.

· Childcare support.

· Transportation supports.

· Coaching, advising, navigation, or case management resources.

· Other services or resources that may help the user obtain, maintain, or advance in employment.

The pathway should help users understand not only the next recommended step, but also why the 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 to help the user successfully complete that step.

As users complete education, training, employment, or other milestones, the Portal should update the pathway to reflect progress and present additional recommended next steps. For example, after a user completes an education or training step, the Portal may identify higher-paying positions in the user’s area that align with the user’s completed training, experience, skills, and long-term goals. The Portal should also identify related supports that may help the user obtain, maintain, and advance in those positions.

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. The guest pathway shall operate entirely within the portal’s stateless session model and shall not persist any data. Guest users shall be able to print, email, or text their generated pathway. The solution shall provide a continuous option for the user to create an account and save the information, parameters, and metadata used to generate the pathway so that the pathway can be redisplayed or regenerated without storing API delivered or session-based data.

The user interface should allow users to view their personalized pathway in more than one format. At a minimum, the Portal should allow users to switch between:

· A graphical pathway, roadmap, timeline, journey, or similar visual view that shows progression, milestones, sequencing, and next steps.

· A structured list, table, checklist, hierarchy, or similar detailed view that displays the same information in a more organized format.

Users should be able to move between these views without duplicating data, losing context, or requiring separate manual entry. Both views should reflect the same underlying pathway information, including goals, milestones, recommended steps, status, due dates, locations, costs, eligibility requirements, available resources, and progress.

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 regenerate and redisplay each saved pathway by using the stored parameters and metadata. Users shall be able to assign custom names to their saved pathways and select any saved pathway for redisplay. The solution shall not store API delivered or session-based data as part of a saved pathway. User initiated exports such as PDF, printed copies, emailed copies, or texted copies shall be supported.

The solicitation does not prescribe a specific visual design, layout, terminology, AI model, or user-interface approach. The Contractor will propose its recommended approach, provided the proposed solution satisfies the objectives and requirements described in this solicitation, supports accessibility and usability, protects privacy and consent, and allows users to understand their pathway, recommended next steps, available supports, progress, and future opportunities without duplicating data or requiring separate manual entry across views.

C.3.2.1.2. Pathway View Demonstration and Acceptance. The Contractor shall demonstrate how the proposed solution will present the same pathway information through both a graphical pathway, roadmap, timeline, journey, or similar visual view and a structured list, table, checklist, hierarchy, or similar detailed view. The demonstration must show how a user moves between views without duplicate data entry, loss of context, inconsistent status, or conflicting information. During implementation, these pathway views shall be subject to State review and acceptance based on usability, accessibility, plain-language presentation, mobile responsiveness, consistency of underlying data, and the ability of users to understand current position, recommended next steps, available supports, progress, and future opportunities.

To align with the State’s Service Capability Framework (SCF), the Contractor’s solution must deliver functionality across four core areas:

· Common Portal Capabilities

· Education Capabilities

· Workforce Development Capabilities

· Support Services and Wraparound Assistance Capabilities

The Contractor solution must fulfill the following RTM outcomes.

C. 2.1.3. Area 1: Common Portal Capabilities: These foundational capabilities span all user personas and must be native to the Portal experience.

· Identity, Privacy, and Client Account Management: The system must support diverse user account types, including students, job seekers, employers, and educators, with role-based access and guardian-learner relationships. The system must allow users to securely connect third-party profiles, manage opt-in and opt-out consent preferences, and maintain a registry of active Memoranda of Understanding (MOUs) and Data Use Agreements (DUAs) governing cross-agency data sharing.

This must include approved OAuth/OpenID Connect authentication, selective field import, user preview and edit controls, token protection, the ability for the user to disconnect a connected third-party profile at any time, and prohibition on any password collection, profile scraping, or use of unofficial access methods. LinkedIn is one example of a third-party profile provider that would require these protections. The portal shall support an employer verification capability that validates employer identity, business legitimacy, and authorized representative status. When an employer creates an account in the portal, the system shall automatically check SCWOS to determine whether the employer already exists and is verified. If the employer is not found in SCWOS, the portal shall submit the employer’s information to SCWOS for verification and account creation. Employers verified through SCWOS shall automatically be recognized as Portal‑verified employers without requiring duplicate verification and shall have access to employer‑specific workflows, including job posting, AI‑assisted job description creation, and employer‑initiated outreach, while remaining within the portal experience. The portal shall provide a public employer profile that displays State‑approved employer information, including verification badges, job postings, employer descriptions, and other publicly visible content. Public employer profiles shall be accessible to job seekers, students, educators, and other authorized users and shall comply with State‑approved privacy, consent, youth‑protection, and accessibility requirements. Only information designated as publicly visible by the State and the employer shall appear on employer public profiles. The portal shall apply required trust criteria for issuing a Portal‑Verified Employer Badge using objective, automatable checks derived from publicly available sources. Required criteria shall include business registration match, FEIN or State Business ID validation, authorized representative verification, automated fraud‑prevention screening, years in business based on State registry data, presence of at least one public review on widely used platforms (e.g., BBB, Google, Apple, Yelp), domain age verification, publicly listed business contact information, and confirmation that the employer is not flagged on State‑approved scam or abuse lists. The portal may request a link to the employer’s public job board to verify active job‑posting history; if the employer does not provide a link, the system shall prompt the employer twice before allowing submission without this optional criterion. All trust criteria shall be fully automatable and shall not expose sensitive employer information beyond verification status. The portal shall display verification badges on employer public profiles that indicate the employer’s verification status. Employers meeting required trust criteria shall receive a “Portal‑Verified Employer Badge.” Employers verified through SCWOS shall receive a “SCWOS‑Verified Employer Badge.” Employers meeting both criteria shall display both badges on their public profile, job postings, and candidate‑facing employer views. All badge designs, labels, icons, colors, placement, and accessibility behaviors shall be subject to State review and approval prior to implementation to ensure consistency with State branding, accessibility standards, youth‑protection rules, and privacy requirements. Verification badges shall be subject to a State‑approved recertification cycle that automatically revalidates required criteria at defined intervals (e.g., annually) using automated checks and publicly available data sources. Badge display shall not expose any sensitive employer information beyond verification status. Verification badges shall be displayed only within the FYF Portal and shall not be transmitted to, displayed within, or stored by SCWOS or any other partner system. Badge visibility shall be limited to portal‑based employer public profiles, portal‑generated job‑seeker views, and State‑approved employer‑facing or public‑facing interfaces within the portal. Because the FYF Portal does not provide a general job board, job‑posting‑related badges shall only appear in job‑seeker pathway views, search results, or other portal experiences where job postings are surfaced, and in modules that include a public job board such as internships, volunteer opportunities, or other State‑approved posting destinations. Badge placement shall comply with the portal’s stateless integration model and shall not require SCWOS or partner systems to store or display badge information.

The solution shall support State-approved consent persistence rules. When a user grants authorization for a specific data connection, profile import, or AI-assisted action, the system must allow the State to configure whether:

· Each individual use requires a new explicit approval.

· The initial approval remains in effect until the user revokes it.

· The approval must be renewed after a defined period or under defined conditions.

If persistent approval is enabled, the system must ensure that the user’s original consent is clearly documented, visible, and revocable at any time. The system shall not duplicate or re-collect consent unnecessarily but must re-prompt the user when required by State policy, data-sharing agreements, or applicable law.

· Parent and Guardian Portal Experience: The solution shall support role-based parent and guardian accounts and related workflows for users who are legally authorized to act on behalf of, support, or participate in the education, training, workforce, or service journey of a learner or dependent user. Parent and guardian functionality shall support guardian-learner relationships, parental or guardian consent management, youth protection controls, age-based access rules, privacy controls, and role-based permissions that may vary by user age, program, agency policy, legal authority, and State-approved configuration.

The parent and guardian experience should allow authorized parents and guardians to view, support, and, where permitted, act on relevant tasks, milestones, pathway steps, education or training activities, document requests, consent requests, appointment reminders, communications, referrals, and service coordination activities. The Portal shall allow the State to configure what information a parent or guardian may view, submit, approve, decline, receive, or update, including differences between minor users and adult users.

The solution shall not provide parents or guardians access to learner, job seeker, education, workforce, support service, or agency information unless such access is authorized by applicable law, policy, consent, role-based access rules, data-sharing agreements, and State-approved security controls. Parent and guardian capabilities shall include, where applicable and authorized, the ability to receive notifications, review and confirm information before submission, upload or reuse documents, support completion of intake or program-related tasks, communicate with authorized staff, view recommended resources, and understand how pathway steps, support services, education options, training opportunities, and employment-related activities may affect the learner or dependent user’s progress.

· Policy Leader and Executive Decision Support: The solution shall support role-based dashboards, analytics, reporting, and decision-support tools for authorized policy leaders, executives, agency leadership, program leadership, and other State-approved decision makers. These tools shall provide statewide, regional, local, program-level, and population-level views of Portal activity, service demand, pathway participation, education and training engagement, workforce outcomes, employer engagement, support service navigation, referral activity, opportunity coverage, geographic gaps, user progress, and other State-approved performance indicators.

Policy leader functionality shall allow authorized users to filter, compare, and analyze information by geography, program, population, timeframe, user type, partner, service category, pathway stage, industry sector, credential area, referral status, and other State-approved dimensions. Dashboards and reports should support plain-language definitions, documented data sources, calculation logic, data lineage, refresh cadence, export options, and configurable views appropriate for operational, strategic, legislative, budgetary, policy, and continuous improvement purposes.

The solution shall protect individual privacy and shall use aggregated, de-identified, anonymized, or appropriately permissioned data for policy leader views unless access to identifiable information is expressly authorized by applicable law, policy, consent, role-based access rules, data-sharing agreements, and State-approved security controls. Policy leader dashboards and reports shall not override agency systems of record or create unauthorized eligibility, benefit, enforcement, or program determinations. Any AI-supported insights must follow NIST SP 1270 and the South Carolina Statewide AI Strategy to ensure transparency, explainability, and appropriate human review.

· Expanded Case‑Management Interoperability Capability: The Contractor shall describe and price an expanded interoperability capability that enables the FYF Portal to support cross‑program coordination across multiple case‑management systems. This capability must leverage the portal’s federated data architecture, Integration Layer, Identity and Security Layer, and Counselor, Navigator, Advisor, and Case Manager Workbench. The Contractor shall identify required modules, data structures, workflow engines, security controls, consent rules, and operational processes necessary to support deeper interoperability with SCWOS and other State‑approved systems. This capability shall not replace or supersede any existing case‑management system and must be achievable through modular expansion consistent with the State’s flexibility, sequencing, and lifecycle requirements.

· Counselor, Navigator, Advisor, and Case Manager Workbench: The solution shall support role-based tools for authorized counselors, navigators, advisors, case managers, and similar support staff who assist users across education, workforce, and support service pathways. The workbench shall allow authorized staff to view and manage assigned or authorized users, subject to role-based access controls, consent rules, privacy requirements, youth protection requirements, data-sharing agreements, and State-approved configuration.

The workbench should support caseload management, user search, user status views, pathway review, milestone tracking, task assignment, appointment scheduling or tracking, referral initiation and follow-up, warm handoff tracking, document request tracking, notes or interaction history where permitted, communications, alerts, reminders, and escalation workflows. Authorized staff should be able to help users understand recommended next steps, available supports, education and training options, employment opportunities, barriers to progress, and required actions without replacing the authoritative systems of record used by participating agencies or partners. Enhanced Case‑Management Interoperability: The Contractor shall design all case‑management integrations, schemas, workflows, and data structures to support expanded interoperability across education, workforce, and support‑service programs. This includes the ability to exchange service‑plan components, referral workflows, appointment information, milestone updates, and case‑note metadata with SCWOS and other State‑approved systems only for cases where the user has been positively matched and access has been authorized by the case‑management system owner. The Contractor shall identify any modules, configuration, or implementation services required to support deeper interoperability over time, including expanded cross‑program coordination, while ensuring that partner case‑management systems retain full control over data access, visibility, and permissions. All case‑management data displayed in the FYF Portal shall be accessed and presented as volatile, session‑based data, consistent with the portal’s stateless integration model, and shall not be stored, cached, or persisted unless expressly authorized by the case‑management system owner, user consent, and applicable data‑sharing agreements.

The solution shall allow the State to configure staff roles, permissions, visibility, supervisory access, confidentiality restrictions, program boundaries, regional boundaries, and assignment rules. Counselor, navigator, advisor, and case manager functionality shall support reporting on caseloads, referrals, task completion, pathway progress, service coordination activity, response times, outcomes, and other State-approved operational metrics while protecting confidential and sensitive user information. Any AI-supported insights must follow NIST SP 1270 and the South Carolina Statewide AI Strategy to ensure transparency, explainability, and appropriate human review. The Workbench shall be architected to support expanded interoperability with multiple case‑management systems. The Contractor shall ensure that caseload views, service‑plan elements, referral statuses, appointment information, and case‑note metadata can be retrieved from and routed to SCWOS and other State‑approved systems in accordance with role‑based access, consent rules, and data‑sharing agreements. The Contractor shall identify any additional modules, configuration, or implementation services required to support deeper interoperability over time, including expanded cross‑program coordination, while maintaining SCWOS and other partner systems as the authoritative systems of record.

· User Community and Mentorship Function: The solution shall provide a secure, moderated user community that supports user-to-user communication, peer learning, information sharing, and mentorship connections within State-approved…