RFI 26-87669 Att B - Q&A State's Response - 07.20.2026.xlsx
XLSX spreadsheet 35 KB Posted
- Solicitation number
- RFI 26-87669
- Issued by
- Marion County, Indiana
About this file
This is a Questions and Answers document issued by the Indiana Department of Education (IDOE) in response to vendor inquiries regarding RFI 26-87669 for the Hoosier Launch Advising Tool Platform. The RFI sought vendor information on a career advising platform designed to support Indiana's new high school diploma requirements by tracking student progress toward diplomas and readiness seals, documenting work-based learning hours and credentials, and enabling seamless data transfer when students change schools. The platform must serve all Indiana high schools and approximately 480,000 students in grades 7-12, with core capabilities including career exploration tools with interest inventories, course and experience recommendations, dual-credit attainment monitoring, internship and job search integration, employer certification of work-based learning, student portfolios, graduation plan creation and tracking, mobile apps for students and families, and school-level reporting. Written questions were due July 2, 2026 at 3:00 PM Eastern Time, with State responses provided by July 20, 2026, and RFI responses due July 27, 2026 at 3:00 PM Eastern Time.
The State clarified that IDOE will serve as the authoritative source for diploma progress evaluation and will own the business logic of the diploma, providing data to vendors through a Comprehensive Learner Record (CLR) standard rather than through a state-owned cloud tenant requirement. Vendors must complete the State's badging certification process to connect to IDOE APIs and access secure student data, though schools retain discretion to select any platform for implementation. The IDOE will not procure a single statewide vendor but will maintain a certified vendor list of platforms meeting security and functional compliance standards. Data integration will use Ed-Fi as the first choice standard for data flowing from vendors to IDOE and CLR format for data flowing from IDOE to vendors. Vendors must demonstrate WCAG 2.2 AA accessibility compliance, support language translation, integrate with MuleSoft and GoAnywhere Managed File Transfer services, and comply with NIST 800-53 Revision 5 standards. The State indicated this RFI serves as a landscape review to understand vendor capabilities and that no formal procurement contract will result directly from this solicitation.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFI 26-87669 Att E - Hoosier Launch SOW.pdf | ||
| RFI 26-87669 Att B - Q&A Template.xlsx | XLSX spreadsheet | |
| RFI 26-87669 Appendix A Platform Capabilities and Features.xlsx | XLSX spreadsheet | |
| RFI 26-87669 Att A - Response Template.docx | DOCX document | |
| RFI 26-87669 Main Document.pdf | ||
| RFI 26-87669 Att C - Artificial Intelligence - Technical Proposal Questions.docx | DOCX document | |
| RFI 26-87669 Att D - Infrastructure Overview.docx | DOCX document |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Q&A
| RFI 26-87669 Hoosier Launch Advising Tool Platform | ||||
| Questions and Answers | ||||
| Attachment B | ||||
| Please submit your questions in the blue shaded areas by the date and time established in the RFI. | ||||
| # | DOC NAME (RFI or Attachment) | PAGE # AND/OR SECTION # | RESPONDENTS QUESTION | STATE'S RESPONSE |
| 1 | RFI | Scope of Work / Attachment A | For the initial pilot or preferred-provider implementation, can IDOE clarify the expected data-source model for student records? |
a. Should vendors expect to consume student data only from State-provided Data Exchange/API services, directly from LEA systems, directly from existing CCR platforms, or from a combination of those sources?
| b. If a combination is expected, which source should be treated as authoritative for student identity, enrollment, course history, diploma pathway status, WBL, credentials, and dual credit? | IDOE would expect to provide authoritative data to receiving systems. The authoritative data would include: student identity, enrollment, course history, diploma pathway status, WBL, credentials, dual credit and status against Indiana's diploma requirements. The IDOE would not require consuming systems to limit their data consumption to IDOE provided data since there may be more data that could be used to support students and families in their pursuit of relevant secondary experiences aligned to their stated post secondary goals. | |||
| 2 | RFI | Scope of Work / Attachment A | Can IDOE identify the expected student-level data domains for initial implementation? |
a. Should vendors plan for enrollment, identifiers, demographics, course history, credits, grades, attendance, diploma pathway status, readiness-seal progress, credentials, dual credit, WBL hours, WBL artifacts, career interest inventory results, employer certifications, and opportunity participation records?
| b. Are any of these domains optional, future-phase, or dependent on LEA participation? | IDOE would be supplying any data we already have from schools that is relevant to the determination of diploma progress. It is possible this data will vary across schools especially in the area of WBL hours, artifacts, career inventory results etc. which we do not formally collect at the IDOE. However, since these data elements are of interest and relevant to student diploma progress we would be working in future phases to ensure such data is part of the student record on file at the IDOE. It is our intent to focus on communnicating the status of students with regard to their stated post secondary goals (diploma seal) using flags such as non achieved, in progress, achieved/complete based on a standard digital definition of the diploma and an evaluation of a students data against that definition. If there is missing data that prevents us from providing a status on a particular dimension of the diploma, that will be clear. We will make our determinations based on the best data available to us. | |||
| 3 | RFI | Scope of Work / Attachment A | Will IDOE provide implementation data specifications before vendor configuration begins? |
a. Will IDOE provide data dictionaries, API schemas, sample payloads, test data, validation rules, credential catalogs, diploma/readiness-seal rule definitions, WBL definitions, and reporting metric definitions?
| b. If those materials are not available at RFI response time, when should vendors assume they will be available to the selected provider? | Yes, IDOE will have a vendor certification process that is used to ensure each participating vendor can meet minimum technical requirements. In order to prepare vendors for this process we will be publishing data dictionaries, API schemas, sample payloads, test data, validation rules, credential catalogs, diploma/readiness-seal rule definitions, WBL definitions, and reporting metric definitions? For API integrations and documentation we typically make a Swagger site available to document available endpoints. | |||
| 4 | RFI | Scope of Work / Attachment A | Can IDOE clarify the authorization model for data access in Hoosier Launch? |
a. Will data access be authorized centrally by IDOE for a statewide Hoosier Launch deployment?
b. Will each participating LEA need to approve and provision its own data-sharing connection with the selected vendor?
| c. If LEA-specific approvals are required, should vendors assume phased onboarding by LEA readiness? | Some of these details are still being discussed but at a minimum we will need to determine which vendors are acting on behalf of which schools. Our typical practice is to then issue API keys and secrets for each certified vendor/school combination. We currently use this process to manage all school data flowing to the IDOE for 15 vendors across the state. | |||
| 5 | RFI | Scope of Work / Attachment A | Should vendors expect to receive historical student records for initial implementation? |
a. If yes, which historical domains should be included, such as diploma pathway status, WBL history, credentials, dual credit, grades, course history, career goals, and artifacts?
b. How many years of historical data should vendors assume?
| c. Should historical records be loaded centrally, by LEA, or by another process? | Any historical records flowing to the vendors will occur as part of a package relevant to the determination of diploma status for each student. For example, for a senior the student data package will include any courses that student is currently taking as well as any credit bearing courses from prior academic years including any credit bearing courses from middle school. Any data the IDOE has about this student that would help to determine if they have completed a requirement of the diploma they are pursuing will be part of the student data package along with a determination of the student's status vis-a-vis any of the seals possible in the new diploma. We plan to evaluate a student's academic history and current enrollments in light of all of the requirements for any seal in the new diploma so that vendors can support scenario based exploration on the part of studnets (e.g., what happens if I change the diploma seal I'm currently pursuing to a different seal?). We have all the historical data any school has sent to us for any purpose and will organize that data by student to deliver an authoritative status on the diploma to certified vendors acting on behalf of the school where a student is enrolled. | |||
| 6 | RFI | Scope of Work / Attachment A | What data refresh cadence does IDOE expect for inbound and outbound student-level records? |
a. Should vendors assume real-time API updates, scheduled batch files, event-based updates, nightly sync, or another cadence?
| b. Are any data domains expected to update faster than others, such as enrollment, attendance, WBL hours, credentials, or readiness-seal progress? | The data for this project will likely not be refreshed very often. Data elements that will change frequently (attendance, course enrollments, workbased learning hours, etc.) should be able to be reflected in near real time. We would work toward refresh options that were efficient (delta) with system resources. | |||
| 7 | RFI | Scope of Work / Attachment A | Can IDOE clarify the expected outbound reporting and write-back responsibilities? |
a. Should vendors send completed pathway, WBL, credential, dual-credit, and readiness-seal records back to IDOE as the system of administrative record?
b. Or should vendors provide reporting extracts while another IDOE system remains the administrative record?
| c. Will IDOE provide required outbound formats and validation rules? | There are diploma related data elements that IDOE does not collect currently. The long term goal would be to collect any data elements relevant to the diploma in the most efficient way possible. If these data elements come from vendors that are also consuming the student data file from the IDOE, we would merge data received from the vendor into the student record and assess how this data influences the student's status on diploma completion and share this status back to the vendor. For example, if work-based learning hours are collected by a CCR platform we would work with vendors capable of writing back such records to the IDOE. This would include standardizing the write back format and validation rules for sending work-based learning hours. The IDOE would then add the workbased learning hours to the student data file and expose those hours to our diploma validation logic which would then produce an updated status for the student which reflected how those WBL hours impacted diploma progress. This new status would become available for that same vendor to consume from the IDOE through the API. | |||
| 8 | RFI | Scope of Work / Attachment A | Does IDOE expect direct student login in the initial platform release? |
a. May the first release focus on counselor and school-staff access, with student-facing access phased in later?
| b. If student login is required at launch, which student-facing workflows must be available on day one? | IDOE assumes vendors are managing system level access to their platforms. We are agnostic to how this works. Presumably, student and family access is a feature of the platforms in which many schools are already investing. The decision about how to stage access would be something that shoudl be worked out between the vendor and the school. | |||
| 9 | RFI | Scope of Work / Attachment A | Is family or parent/guardian access required for the initial release? |
a. If yes, should families see the same student view, a limited guardian view, or configurable access based on student age, consent, LEA policy, or guardian relationship?
| b. Should parent or guardian accounts support multiple students in one family account at launch? | IDOE assumes vendors are managing system level access to their platforms. We are agnostic to how this works. Presumably, student and family access is a feature of the platforms in which many schools are already investing. The decision about how to stage access would be something that shoudl be worked out between the vendor and the school. | |||
| 10 | RFI | Scope of Work / Attachment A | What identity providers or authentication methods should vendors assume for Hoosier Launch user groups? |
a. Should authentication be State-managed, LEA-managed, vendor-managed, or mixed by user type?
b. What authentication approach should vendors assume for students, parents/guardians, school staff, employers, intermediaries, and IDOE administrators?
| c. Will IDOE provide SSO, role, group, or provisioning specifications during implementation? | The focus of authorization for the IDOE will be addressing how IDOE provides authorized access our API infrastructure for certifed vendors. We are not planning to mediate user access on school level platforms. This is part of the overall design of Hoosier Launch. Vendors, we believe, will deliver industry standard platform capabilities to the schools with whom they are contracting. It would certainly be our hope that schools are investing in platforms which provide a primary service to students and families while providing support to school administrators and counselors. | |||
| 11 | RFI | Scope of Work / Attachment A | Can IDOE clarify what post-high-school account access means for this RFI? |
a. Does IDOE expect continued student login after graduation, data export to the student, account transfer to a personal email, alumni access for WBL/credential records, or another model?
| b. What retention period should vendors assume for post-high-school account and pathway records? | This reference in the RFI is intended to develop an understanding of how evolved the vendor community is in this area. It is not an expectation that all vendors currently provide this capability. Since our current plan is to deliver student data to vendors using the Comprehensive Learner Record format, we believe there may be some utility and benefit to Hoosier students who have access to this record and other records produced in vendors systems following graduation. IDOE will not establish a retention criterion since the Hoosier Launch model has vendors as secondary consumers of data produced by schools. | |||
| 12 | RFI | Scope of Work / Attachment A | Should student profiles be portable across LEAs statewide when a student transfers schools? |
a. If yes, what statewide identifier, consent, data-sharing, and record-ownership rules should control that transfer?
| b. Should the receiving LEA inherit prior WBL, credential, dual-credit, career, and pathway records automatically or after approval? | While there are some remaining i's to dot and t's to cross on this topic, the general rule is that when a student enrolls in a school, that school immediately begins to send enrollment data for that student to the state. This is currently happening for all schools across the state. The IDOE will then begin to share this student's data with the vendor currently contracting with that school. This will allow the totatlity of the relevant student record on file with the state to be sent to the vendor at the new school. IDOE acts as the agregator of academic history and the authoritative source of how this academic history stacks up against the requirements of the new diploma. IDOE will serve as a data hub in this model. The vendors are the spokes and the student data are the train cars that can go to any authorized vendor serving the school where the student is enrolled. | |||
| 13 | RFI | Scope of Work / Attachment A | Are employers and intermediaries expected to log directly into the platform? |
a. Should employers or intermediaries be able to post opportunities, verify WBL hours, review artifacts, and certify experiences?
b. Or should schools and LEAs enter and verify those records on behalf of employers and intermediaries?
| c. If direct access is expected, what identity, role, and approval process should vendors assume for non-school users? | A current statewide market place for posting opportunities does not yet exist. This is part of the Hoosier Launch vision but not during the pilot phase. We would want to implement this in a way that has the least amount of friction for employers to post their opportunities. Furthermore, we would want such a marketplace to act as a complement to any opportunites a vendor may already have flowing into their platform. We would need to solve a number of issues to implement this including access for non-school users etc. Most likely the data about opportunities in such a marketplace, would be consumed by vendors through an API. We would organize this service to fill a hole that is not already being filled by the market. In other words, we want this to addititive in nature to give the most opportunities possible to Indiana students. Some vendors are already doing excellent work in this space. IDOE would be looking to establish a floor of access to internships, apprenticeships and opportunities. | |||
| 14 | RFI | Scope of Work / Attachment A | Will IDOE provide a central feed or registry of opportunities and approved providers? |
a. Should vendors expect a central registry for internships, work-based learning opportunities, employers, intermediaries, credentials, and approved providers?
| b. Or should vendors integrate with regional/local partners and existing CCR platforms for those opportunity records? | A current statewide market place for posting opportunities does not yet exist. This is part of the Hoosier Launch vision but not during the pilot phase. We would want to implement this in a way that has the least amount of friction for employers to post their opportunities. Furthermore, we would want such a marketplace to act as a complement to any opportunites a vendor may already have flowing into their platform. We would need to solve a number of issues to implement this including access for non-school users etc. Most likely the data about opportunities in such a marketplace, would be consumed by vendors through an API. We would organize this service to fill a hole that is not already being filled by the market. In other words, we want this to addititive in nature to give the most opportunities possible to Indiana students. Some vendors are already doing excellent work in this space. IDOE would be looking to establish a floor of access to internships, apprenticeships and opportunities. | |||
| 15 | RFI | Scope of Work / Attachment A | Does "preferably mobile application friendly" require a native mobile application? |
a. Will a responsive web application or progressive web app satisfy the student and family mobile-access expectation?
| b. If a native mobile application is preferred, is it required at launch or acceptable as a later phase? | This is not a requirement for launch (and may never be a requirement). We simply trying to understand what the market looks like. We assume the market will push vendors toward mobile friendly interfaces and rich interactions but we are leaving this to the market to drive. | |||
| 16 | RFI | Scope of Work / Attachment A | Should vendors mark "In Production" based on capabilities available in their current platform generally, or only capabilities already configured specifically for Indiana diploma requirements, readiness seals, WBL workflows, and IDOE data standards? |
a. If a current platform capability requires Indiana-specific configuration, should vendors mark it as In Production, On Product Roadmap, or In Production with explanatory notes?
| b. Should target release dates reflect a general product roadmap or the anticipated Hoosier Launch implementation timeline? | Mark "in production" based on capabilities in current platform. Use your current product roadmap dates and planned release schedule. Again, we're trying to understand the maturity of this space and which features are generally available across existing system, which ones are on the near horizon, and which features are longer-term plays. | |||
| 17 | RFI | Scope of Work / Attachment A | Is Ed-Fi a required integration standard for the initial response, or an example of an acceptable open standard? |
a. Which data exchanges, if any, must use Ed-Fi at launch?
| b. Which exchanges should use MuleSoft APIs, GoAnywhere MFT, or other State-approved methods? | Indiana has adopted the Ed-Fi data standard as the central piece of our Data Exchange platform -- the platform by which we gather data from schools. This standard would be our first choice for consuming data from Hoosier Launch vendors but this will be determined by the coverage the Ed-Fi model provides for the data eleements of interest. As for the data flow coming from the IDOE to vendors, we are likely to create comprehensive learner records (CLR) as the mechanism for transporting academic history and progress on the diploma seals to the vendors. | |||
| 18 | RFI | Scope of Work / Attachment A | Can IDOE clarify the State-owned cloud tenant requirements for RFI responses and later implementation? |
a. Is deployment in a State-owned cloud tenant mandatory for RFI responses, mandatory for a later implementation, or the State's preferred hosting model?
b. If a State-owned tenant is used, does IDOE or IOT have a preferred cloud provider and prescribed services for hosting, identity, logging, monitoring, backup, key management, and secure file transfer?
| c. What access level would the selected vendor receive in a State-owned tenant for deployment, monitoring, support, updates, incident response, and audit-log access? | This is a good question but probably not relevant for Hoosier Launch. The contracts for vendor services will not be with the state of Indiana but rather between vendors and schools. As such, the state will not be enforcing any of the terms related to a state-owned cloud tenant. This is boilerplate language included in all RFI's but not material to this solicitation. | |||
| 19 | RFI | Scope of Work / Attachment A | What AI evidence does the State expect at the RFI response stage? |
a. Should vendors provide model-card examples, de-identification documentation, AI logging examples, and AI enable/disable control descriptions with the RFI response?
| b. May detailed artifacts that include security-sensitive implementation details be provided after shortlisting, award, or under controlled disclosure? | We are trying to understand the basic landscape of the field of respondents. We don't need any proprietary disclosures. Simply want to know generally how AI is being leveraged to make your product better. | |||
| 20 | RFI | Scope of Work / Attachment A | Which accessibility and compliance artifacts are required with the RFI response versus during implementation? |
a. Does WCAG 2.2 AA require a current VPAT or third-party accessibility audit at RFI submission?
b. May vendors provide an accessibility commitment with formal validation during implementation?
| c. Are language translation requirements, supported languages, and accessibility test formats expected to be finalized in the RFI response or during implementation discovery? | The information about accessibility and language support would be great information to have for our landscape understanding. IDOE is not entering into a contract as a result of this solicitation so the information we are asking you to disclose here is to hep us understand these dimensions of the market and to understand the penetration of features and capabilities across the state. | ||||
| 21 | RFI Main Document | Eligibility statement ("school corporations are not eligible to apply for the RFI directly") | The RFI cover memo states school corporations are not eligible to apply directly, and encourages schools to engage through their current platform provider. New Castle Community School Corporation has developed and maintains a PowerSchool plugin suite (Diploma Tracker and CTE Tracker) currently in production use at New Castle and three additional Indiana school corporations (Muncie Community Schools, Matchbook Learning of Indianapolis, and Daleville Community Schools), tracking student progress toward Indiana diploma types, readiness seals, and CTE requirements. There is no separate private corporate entity behind this product — New Castle Community School Corporation itself develops and supports it for the other participating districts. Could the State clarify how a respondent in this position — a school-corporation-developed and -supported tool already used by multiple LEAs, rather than a traditional ed-tech company — should structure or identify itself as the Respondent for this RFI? | The plan for Hoosier Launch is that the IDOE will be the authoritative source of evaluation of diploma progress. What this means is the IDOE will own the business logic of the diploma. We are trying to avoid having multiple definitions of the diploma and risking the possibility that students receive different messages from different vendors about progress on the diploma. If New Castle would like to respond to the RFI you are welcome to do so. As described the product you are describing is is not the target of this effort. Also, Hoosier Launch leaves it to schools to decide how they are going to support the implementation of the new diploma for 2029. Schools will not be required to adopt a College and Career Readiness platform that can connect with the API being developed by the IDOE. The IDOE will be making data available to platforms that are helping students to navigate the options and opportunities available to ready them for their post secondary pursuits. We are trying to standardize the diploma tracking part of this. | |
| 22 | Att D | If vendor agrees to go with a State-Owned Cloud Tenant in Microsoft Azure, are there specific Azure resources that are restricted or won’t be available? | This is a good question but probably not relevant for Hoosier Launch. The contracts for vendor services will not be with the state of Indiana but rather between vendors and schools. As such, the state will not be enforcing any of the terms related to a state-owned cloud tenant. This is boilerplate language included in all RFI's but not material to this solicitation. | ||
| 23 | Att D | How is configuration and access to Azure resources handled in a State-Owned Cloud Tenant? Does the vendor have full authority to make changes to these resources? Can the resources be set up to match our preferred environment? | This is a good question but probably not relevant for Hoosier Launch. The contracts for vendor services will not be with the state of Indiana but rather between vendors and schools. As such, the state will not be enforcing any of the terms related to a state-owned cloud tenant. This is boilerplate language included in all RFI's but not material to this solicitation. | ||
| 24 | Att D | Is the State open to a hybrid arrangement where data is stored on state-managed resources and the vendor hosts their own code and interopability layer? | This is a good question but probably not relevant for Hoosier Launch. The contracts for vendor services will not be with the state of Indiana but rather between vendors and schools. As such, the state will not be enforcing any of the terms related to a state-owned cloud tenant. This is boilerplate language included in all RFI's but not material to this solicitation. | ||
| 25 | Att D | In a State-Owned Cloud Tenant, will Vendors have direct acces to rollout new features and hotfixes? Can vendors deploy code continuously or only during state-approved change windows? | This is a good question but probably not relevant for Hoosier Launch. The contracts for vendor services will not be with the state of Indiana but rather between vendors and schools. As such, the state will not be enforcing any of the terms related to a state-owned cloud tenant. This is boilerplate language included in all RFI's but not material to this solicitation. | ||
| 26 | Att D | In a State-Owned Cloud Tenant, what are the DR/RTO/RPO requirements, and who owns backups? | In a State‑Owned Cloud Tenant, the State typically establishes DR, RTO, and RPO requirements in accordance with IOT standards. The State generally owns and manages backups unless another arrangement is specified in the contract. Please describe how your solution aligns with State‑managed backup and recovery processes and what options your product supports. | ||
| 27 | Att D | In a State-Owned Cloud Tenant, how does monitoring of cloud resources work, and how are issues escalated? | Cloud resource monitoring in a State‑Owned Tenant is usually handled through IOT‑managed monitoring tools and operational processes. Incidents are escalated through existing IOT support channels. Please outline how your solution integrates with third‑party monitoring and what visibility or alerts your product provides. | ||
| 28 | Att D | In a State-Owned Cloud Tenant, does the vendor retain ownership of their intellectual property? | Vendors typically retain ownership of their proprietary intellectual property. The State generally receives usage rights needed to operate the solution and ownership of State specific configurations or deliverables, subject to final contract terms. Please describe your standard IP ownership and licensing model. | ||
| 29 | Att E | Section 1, Page 1 | IDOE is interested in understanding a potential partnership model with existing CCR platforms. Please define partner more clearly. | Partnership in this instance refers to an agreement between the IDOE and participating CCR platforms where the IDOE establishes a direct connection with CCR platforms currently serving one or more Indiana school corporations to efficiently provide authoritative data related to student progress and graduation requirements to enhance the services and support provided to schools in Indiana in exchange for the CCR platforms providing data back to the IDOE (with approval of the partner school corporation) to streamline data collection and reporting for Hoosier schools. During the initial pilot, work will focus on establishing a secure data connection from IDOE to participating CCR platforms only. | |
| 30 | Att E | Section 2, Page 4 | For vendors/providers that could possibly sit on both sides of the diagram shared, would you envision providing vendors a bi-directional data path or would the expectation be that vendors/platforms create individual connectivity to a multitude of different systems? Would an interoperable data standard be mandated? | Phase I of this effort will be to share student diploma progress with CCR vendors. In a future phase CCR vendors with diploma relevant data not already collected by the IDOE will be provided with the ability to write data to the IDOE. First choice of data standard for data from vendors to the IDOE will be the Ed-Fi data standard. The plan for the IDOE sharing data to vendors is the Comprehensive Learner Record (CLR) data standard maintained by 1Edtech. | |
| 31 | RFI Main Document | Response Format and Attachments Section / RFI p. 3 | Can IDOA confirm the complete list of documents required for a full RFI response submission? Specifically, is the required package limited to Attachment A (Response Template), Appendix A (Platform Capabilities and Features), and Attachment C (AI Technical Proposal Questions), or are there additional attachments expected? | All documents included are required as part of the response. If any component of your solution aligns with the materials requested, then the corresponding attachment must be submitted. | |
| 32 | Att D | Attachment D, Cloud-Based Service Offering section | Is Attachment D (Infrastructure Overview) required to be completed and submitted as part of the RFI response, or is it provided as reference material only? If it is required, does the N/A option apply to vendors proposing a vendor-hosted SaaS solution rather than a state-owned cloud tenant deployment? | If your solution includes any applicable cloud‑based technology, please complete Attachment D. If not, you may indicate N/A. | |
| 33 | RFI Main Document | Response Format and Attachments Section / RFI p. 3 | The Main RFI states the total response should be 15–20 pages. Does that page limit apply to Attachment A only, or does it include all submitted attachments (e.g., Appendix A, Attachment C, Attachment D)? | The stated limit applies specifically to Attachment A. | |
| 34 | Att E | Attachment E, Section 2.0 Requested Information | The SOW requires the solution to support Indiana's standard data transmission technologies, specifically MuleSoft API Management and GoAnywhere Managed File Transfer. Can IDOA clarify whether vendors are expected to demonstrate existing compatibility with these specific tools at the time of RFI response, or whether a commitment to integrate during implementation is sufficient? | A commitment to integrate during implementation is sufficient. As this RFI is not intended to proceed to an RFP, no additional commitments are required at this stage. However, should any pre‑implementation or audit activities occur prior to awarding a respondent, the ability to demonstrate compatibility would be ideal. | |
| 35 | Att E | Attachment E, Section 2.0 Requested Information | The SOW references a badging process defined by IDOE to verify vendor capability to access secure API data and meet minimum security, functional, and data handling criteria. Can IDOA provide additional detail on the timeline, criteria, and process for completing vendor badging, and whether completion of this badging process is a prerequisite for inclusion on the preferred vendor list? | Badging process will be required to connect to the IDOE API. However, as states in responses to other questions, schools will have latitude to use whatever platforms they want--only vendors who have passed the badging process will be able to connect to the IDOE API. The IDOE will not be maintaining a preferred vednor list--just a certified vendor list. | |
| 36 | Main RFI | 3 | The required response templates themselves are six pages prior to any vendor entry. Would it be possible to expand the maximum response length to 21 to 26 pages to take that into account?(at minimum) | The stated limit applies specifically to Attachment A. | |
| 37 | Appendix A | 1 | Appendix A refers to "Ability to display progress against a defined graduation plan." How are defined graduation plans encoded and transmitted? | IDOE plans to create a digital credential which will be publically available on a digital credential platform. The IDOE will use this digital credential as a point of reference for evaluating student progress towards completion. The details of attainment of the credential will be transmitted to CCR vendors using the Comprehensive Learner Record data standard. The receiving vendor will then parse the data about the student and display whatever elements of the CLR are supported in the interface. | |
| 38 | Att D | 1 | The Infrastructure Overview lays out the minimum requirement, "The State retains full ownership and administrative control over the tenant." Please define full administrative control. Would this include the ability to modify and deploy software? | This is a good question but probably not relevant for Hoosier Launch. The contracts for vendor services will not be with the state of Indiana but rather between vendors and schools. As such, the state will not be enforcing any of the terms related to a state-owned cloud tenant. This is boilerplate language included in all RFI's but not material to this solicitation. | |
| 39 | Att D | 1 | If, as described in the Infrastructure Overview, the requirement that "All data associated with the solution must reside within the State-owned tenant" created interoperability limitations with national systems for applications and record tracking, would that isolation be acceptable to the State? | Respondents should complete the Infrastructure Overview Form according to the assumptions of their proposed solution. If offering a SaaS based solution and/or an application based solution, please provide responses for both Option 1 and Option 2 to the extent you are comfortable. | |
| 40 | Att D | 3 | Beyond district SIS integrations, what statewide systems and agencies should vendors anticipate integrating with to support Indiana's long-term vision? | There is the possibility of multiple state level APIs including an API serving up WBL opportunities, internships, and apprenticeships. The IDOE has already integrated with all SIS vendors currently operating in the state. Hoosier Launch is structured to capitalize on this integration and share the data we've already collected. | |
| 41 | Att E | 1 | Does IDOE envision learner records, credentials, and work-based learning artifacts extending beyond K–12 into postsecondary and workforce experiences? | Not at this time. | |
| 42 | Att E | 1 | What role do existing CCR vendors (e.g., Naviance, Xello, Indiana Career Explorer) play in IDOE's long-term vision? | We believe CCR vendors are in a good position to help schools implement the new diploma as part of their support for students as they work to prepare for their post secondary pursuits. It is IDOE's intent to provide CCR vendors with high quality data and authoritative diploma progress status that can follow a student to any school using any certified vendor. There is lots of work to do to support students in achieving their diploma seals and to position themselves for post seccondary success. The IDOE will support the implementation with robust data management infrastructure while CCR platforms will provide the interface and many other features aimed to help students and families prepare for their futures. | |
| 43 | Main RFI | 4 | What is the long-term procurement strategy following this RFI (statewide platform, preferred providers, or multiple procurements)? | This RFI will serve as a landscape review of sorts. IDOE will digest the responses and develop the badging process by which vendors will be able to become certified (including vendors who didn't respond to the RFP although we will be collecting much of the same information from any vendor interested in becoming certified). The IDOE is not planning to procure a statewide vendor but will maintain a list of vendors who have completed the the certification process. | |
| 44 | Att D | 3 | Does IDOE envision a single statewide platform or an ecosystem of interoperable solutions built around existing CCR platforms? | An ecosystem of interoperable solutions built around existing CCR platforms. | |
| 45 | Att A | 2 | How many students do you estimate this solution supporting? | We would guess an upper limit of 480,000 students (grades 7-12 x 80,000 students per grade level). | |
| 46 | Att E | Section 2.0, Page 2 | Attachment E describes five distinct stakeholder groups: students, families, school staff, employers, and intermediaries. Must a single platform serve all five user types, or may vendors propose solutions that serve a subset of these personas? | The goal is to be able to serve all stakeholders through the platform with different views and access for different user groups. | |
| 47 | Att E | Section 1.0, Page 1 | The SOW references employers being able to post work-based learning opportunities. Will the platform be expected to include employer self-service account creation and management, or will LEA staff or intermediaries manage employer access? | As long as there is a way for the work based opportunities to be posted and tracked through the system, and not a tedious way for the LEAs to manage those opportunities, it should be fine. It would be ideal if you are able to have secured access for the employers in there, as that would ease the burden on the LEAs and school personnel. | |
| 48 | Att E | Section 3.0, Page 5 | The SOW asks vendors to propose performance metrics aligned to IDOE's goals. Can the State share any existing performance benchmarks, baseline data, or KPI frameworks currently in use for student engagement, diploma attainment, or CCR platform adoption? | A lot of individual school data is availbale on the GPS dashboard for the metrics that are aligned to IDOE's goals and metrics. But here are also the 5 strategic priorities for IDOE and everything we do is looked at through these lens: |
1. Student-Centered: To have the most positive impact on student learning, we will keep students top of mind and make every decision based on the needs of individual learners.
2. Inclusive and Collaborative: We are committed to activating communities by engaging partners throughout the state. Our educators are critical partners in our students’ education journeys, and we will prioritize supporting them and elevating our profession.
3. Data- and Results-Driven: We will rely on data and results to shape innovative solutions, guide decision-making, drive student learning, and measure the impact of public policy.
4. Transparent and Trustworthy: We will make accurate data readily available to ensure public understanding.
5. Future-Focused: Since our rapidly changing economy will require continuous education for a growing number of Hoosiers, we will encourage increased innovation within our education to workforce continuum to meet the needs of an uncertain future economy.
49 Att E Data Flow Chart, Page 4 The SOW references a "Mobile App for students and parents" as an expected feature. Is a native mobile application (iOS/Android) required, or would a responsive web application that functions on mobile devices satisfy this requirement? An app based support or framwork is the vision, as it makes entering, reporting, and tracking much easier, and as long as a vision for that exists and in the interim a workaround through web application are well thought out, IDOE would be interested.
&P of &N
File details come from the government source that posted it. Updated .