Response to Offeror Questions document.pdf

Vendor Questions & Answers for RFP# SDBOR06262026 – SDBOR Enterprise AI Platform Implementation Services

July 8, 2026

Vendor A:

AWS / Infrastructure

1. Can SDBOR provide the AWS landing zone architecture, account structure, and any existing infrastructure-as-code (IaC)?

SDBOR intends to establish the AWS landing zone and foundational cloud services necessary to support the platform. While planning and architecture activities have occurred, the environment is not yet fully implemented. The selected vendor should expect to collaborate with SDBOR on validating requirements, recommending architecture and operational approaches, and assisting with implementation activities necessary to support deployment of the Boise State AgentCore Public Stack within a customer-owned AWS environment. Environment-specific documentation and configuration details will be provided during project initiation.

2. Which AWS services are currently approved for use?

O erors should assume the AWS services utilized within the Boise State AgentCore Public Stack represent the baseline platform architecture. Vendors may recommend additional AWS services where they improve security, scalability, operational e iciency, or maintainability.

https://github.com/Boise-State-Development/agentcore-public-stack#-admin-dashboard

3. Are there any constraints related to regions, networking, data residency, or public internet access?

The solution must operate within a U.S.-based AWS environment and support applicable security, privacy, and regulatory requirements. The platform must be securely accessible via the public internet to support faculty, sta , researchers, and students regardless of location. Vendors should assume an externally accessible service protected by appropriate security, monitoring, and access control mechanisms. Additional environment-specific details will be provided during implementation.

4. What environments are required (e.g., development, test, staging, production)?

O erors should assume separate development, testing, and production environments.

Additional environments may be proposed if recommended by the vendor.

5. Who will own and manage AWS cost monitoring post go-live?

SDBOR will retain operational ownership of the platform following implementation. The solution should provide administrative visibility into utilization, operational metrics, and associated AWS costs. Vendors should assume capabilities generally consistent with the Boise State AI Platform (AgentCore Public Stack) baseline platform.

Identity / Access

1. Which Entra ID tenants and identity flows are in scope?

SDBOR currently operates multiple Microsoft Entra ID environments across participating institutions and supports enterprise collaboration through existing federation and governance processes. The selected vendor should assume the solution will need to support a multi-institution identity model while maintaining delegated institutional administration and systemwide governance. RIS maintains a dedicated identity and access management function and will provide subject matter expertise, architectural guidance, and implementation support for identity-related activities. Detailed identity architecture information will be provided during implementation.

2. How are users grouped (e.g., by institution, role, and student/faculty/sta status)?

Users are organized within institution-specific tenant environments that support delegated administration and logical separation of institutional resources. Within each tenant, users are generally classified by functional roles such as students, faculty, sta , researchers, and administrative personnel. SDBOR is currently evaluating the administrative and authorization model that will be used within the platform. O erors should assume support for institution-based tenant segmentation, delegated institutional administration, and role-based access controls within a shared governance framework.

3. Is access primarily controlled via groups, attributes, or a combination of both?

SDBOR anticipates authorization will be based primarily on institution-specific tenant environments, Microsoft Entra ID groups, and role-based access controls. O erors should describe their recommended approach for supporting delegated administration and systemwide governance.

4. Who will manage institutional administrative permissions?

Institutional administrative functions will be managed by designated institutional administrators under governance established by SDBOR.

5. Are guest users, external researchers, or contractors included in scope?

These user populations are not currently in scope. All platform users will require an SDBOR provided credential and required access permissions.

Multi-Tenant / Institutions

1. Should each institution use a separate domain/subdomain, or is a shared portal preferred?

SDBOR prefers a distinct branded experience for each participating institution while maintaining a shared technology foundation and centralized governance model. However, SDBOR is open to alternative approaches, including a shared branded experience, if they provide meaningful benefits in terms of simplicity, manageability, or cost. O erors may recommend a domain and URL strategy that best supports these requirements.

2. What branding assets are available for each of the seven institutions?

Institutional branding assets, including logos, colors, and related materials, will be provided during implementation.

3. Should institutional administrators have visibility limited to their own users, assistants, documents, logs, and costs?

Yes. Institutional administrators should generally be limited to resources, users, assistants, content, analytics, and administrative activities associated with their institution. SDBOR will retain systemwide governance and oversight capabilities.

4. Will assistants be shareable across institutions, or restricted to institution-specific usage?

The platform should support both institution-specific and shared assistants. SDBOR anticipates maintaining the ability to provide institution-specific assistants, systemwide assistants, and other shared resources when appropriate under established governance processes.

Security / Compliance

1. What internal policies must be enforced technically during Phase 1?

O erors should review the requirements contained within the RFP and resulting contract documents. SDBOR is currently developing additional systemwide AI governance requirements focused on security, privacy, data governance, monitoring, auditability, and responsible use of AI technologies. O erors should assume the selected solution will be expected to support these governance objectives in addition to existing SDBOR policies and procedures.

2. Should prompts and responses be logged fully, partially, or redacted?

The platform should provide configurable logging capabilities su icient to support security, compliance, governance, and operational requirements. Vendors should describe how logging can be configured, secured, governed, and retained.

3. Who is authorized to access AI interaction logs?

Access to AI interaction logs should be limited to personnel with approved security, compliance, operational, or governance responsibilities. SDBOR anticipates implementing role-based access controls and oversight processes appropriate for the platform. Specific authorization models will be finalized during implementation.

4. What are the required retention policies for logs, uploaded documents, and chat history?

SDBOR has not finalized retention requirements for all platform data types. The solution should support configurable retention capabilities su icient to accommodate institutional, operational, legal, and regulatory requirements. Vendors should identify available retention, archival, and disposition capabilities within their proposed solution.

5. Which security tools should be integrated at launch (e.g., Sentinel, Red Canary), and are there phased expectations?

SDBOR currently utilizes security monitoring and response capabilities including Microsoft Sentinel and Red Canary. The platform should provide logging and monitoring capabilities that support integration with existing security operations processes. RIS security personnel will support Sentinel and Red Canary integration activities as part of implementation planning. Specific integration requirements and priorities will be determined during implementation.

Knowledge / RAG

1. What document types, size limits, and repositories are included in Phase 1?

SDBOR expects the baseline document ingestion, knowledge repository, and source attribution capabilities included within the Boise State AgentCore Public Stack to be implemented as part of Phase 1. Repository scope, content sources, and operational processes will be refined during implementation. Vendors may recommend practical limits and operating models based on their proposed architecture.

2. Will document ingestion be manual only, or integrated with existing repositories?

Manual document ingestion should be supported as part of the baseline platform capabilities. Vendors may recommend integrations with existing repositories where they provide clear value and can reasonably be accommodated within the Phase 1 timeline and objectives.

3. How should citations/source attribution be presented to end users?

Users should be provided with su icient visibility into the sources used to generate responses. Vendors may recommend approaches consistent with the baseline platform capabilities and industry best practices.

4. Are institution-specific knowledge repositories required from the outset?

SDBOR anticipates supporting institution-specific and shared enterprise content from the outset. O erors should assume appropriate content segregation, access controls, and delegated administration capabilities, while recommending the repository architecture best suited to the platform.

5. Who is responsible for document approval prior to availability in assistants?

Content ownership, approval, and governance responsibilities will remain with SDBOR and participating institutions. The platform should support administrative controls that facilitate those governance processes.

Models / AI Capabilities

1. Which AI models are approved for use?

The Boise State platform supports multi-model architecture. SDBOR anticipates maintaining governance over approved models and model availability within the platform.

Vendors may recommend additional model options as part of their implementation approach.

2. Are commercial APIs permitted, or must models operate exclusively within SDBOR-managed AWS?

The baseline platform supports multiple model integration approaches. Vendors should clearly identify any external services, APIs, or dependencies included within their proposed architecture. SDBOR will evaluate those recommendations as part of the overall implementation approach.

3. Are there usage limits by user, institution, or assistant?

SDBOR anticipates utilizing governance and administrative controls to manage platform usage. The Boise State AgentCore Public Stack includes administrative and reporting capabilities, and o erors should describe any additional usage visibility, reporting, quota management, cost control, or administrative capabilities available within their proposed approach. Specific usage policies and limits have not yet been finalized.

4. Who governs model approvals and lifecycle changes?

SDBOR will retain governance authority regarding approved models and platform configuration decisions. Vendors may provide recommendations to support those governance processes.

Operations / Hando

1. What level of runbooks, administrator training, and knowledge transfer is expected?

The selected vendor should provide implementation-specific documentation, administrator training, and knowledge transfer necessary to support the deployed environment. Existing Boise State AgentCore Public Stack documentation may be leveraged where appropriate. Operational ownership is expected to transition to SDBOR following implementation.

2. Who within RIS will assume platform administration post-transition?

The SDBOR RIS central o ice will retain operational ownership following implementation.

Specific administrative assignments and support models will be finalized during implementation planning.

3. What support coverage is expected during implementation?

O erors should provide su icient sta ing and support resources necessary to meet the project timeline and deliverables. Vendors should identify any assumptions regarding participation by SDBOR resources. RIS anticipates actively supporting implementation activities related to identity and access management, AWS infrastructure, security operations, logging and monitoring, and platform administration. Technical resources with experience supporting the Boise State AgentCore Public Stack and AWS environments will be available to assist throughout implementation.

4. What are the availability, backup, and recovery expectations for Phase 1?

Vendors should propose an approach aligned with AWS’ best practices and enterprise operational requirements. SDBOR anticipates reasonable backup, recovery, and operational resilience capabilities appropriate for a production service.

5. Which monitoring and alerting tools should be used, or should these be proposed?

O erors should propose the monitoring, alerting, and observability capabilities they recommend for the platform, including any assumptions regarding operational ownership and support requirements. SDBOR will evaluate proposed approaches as part of the overall implementation and operational model.

Timeline / Acceptance

1. What are the formal acceptance criteria for Phase 1 completion?

SDBOR anticipates acceptance will be based upon successful implementation of agreed-upon Phase 1 requirements, completion of required integrations, delivery of documentation and knowledge transfer materials, completion of agreed-upon testing activities, and successful transition to operational readiness. Final acceptance criteria will be confirmed during project initiation.

2. Will there be a pilot group prior to full rollout?

SDBOR anticipates utilizing limited user acceptance testing and validation activities prior to broader availability. While adoption may occur gradually over time, the Phase 1 objective is to make the platform available to all participating institutions upon successful implementation. The final testing, rollout, and adoption strategy will be refined during implementation planning.

3. What testing requirements apply (e.g., security, accessibility, UAT, performance, failover)?

Testing is expected to include functional validation, security review, accessibility review, and user acceptance testing at a minimum. Vendors may recommend additional testing activities appropriate to their proposed implementation.

4. Who is responsible for final sign-o on deliverables?

Final acceptance authority will reside with SDBOR. Institutional stakeholders may participate in review and validation activities where appropriate.

5. How will delays related to AWS or identity dependencies be handled relative to the mid- September target?

The target timeline assumes timely availability of foundational AWS services, identity integration activities, project resources, and vendor participation. AWS landing zone implementation, identity dependencies, and other technical prerequisites remain project dependencies. Vendors should identify assumptions, dependencies, risks, and mitigation strategies as part of their proposed approach. SDBOR will work collaboratively with the selected vendor to establish an achievable implementation plan and address identified issues.

Commercial / Proposal

1. Does SDBOR prefer a fixed fee, time-and-materials, or hybrid pricing model?

SDBOR will evaluate pricing approaches based on overall value, scope alignment, assumptions, risk allocation, and completeness. O erors may propose the pricing structure they believe is most appropriate for the engagement.

2. Should future phase pricing be presented as high-level estimates or detailed breakdowns?

Future phase pricing should be provided at a level su icient to support planning and budgeting activities. Detailed estimates for future phases are not required.

3. Are ongoing support services expected following Phase 1?

Operational ownership is expected to transition to SDBOR following implementation and knowledge transfer. Vendors may propose optional post-implementation support o erings if they believe they would provide value.

Vendor B:

Is there an incumbent vendor or implementation partner currently supporting

SDBOR’s AWS environment or enterprise AI platform initiative?

No. This is a new initiative and SDBOR does not currently have an implementation partner responsible for the Phase 1 deployment described in the RFP.

If an incumbent or prior implementation partner exists, what challenges or remaining requirements prompted this solicitation, and is that organization expected to submit a proposal?

Not applicable. This solicitation represents SDBOR's initial procurement for implementation services associated with this initiative.

Is Boise State University, or any organization involved in this RFP, and expected to participate in or submit a proposal for this opportunity?

While we have engaged with both Boise State and AWS on their existing platform and conducted demos, Boise State is not a participant in this RFP.

Will all o erors receive access to the Boise State AI Platform source code, deployment documentation, architecture diagrams, infrastructure-as-code templates, and implementation instructions before proposal submission or only after award?

O erors should utilize the publicly available Boise State AgentCore Public Stack repository and associated documentation when preparing proposals. Additional SDBOR environment-specific implementation information will be made available to the selected vendor during project initiation.

https://github.com/Boise-State-Development/agentcore-public-stack#-admin-dashboard

Please confirm that providing paid implementation, configuration, and support services for SDBOR is permitted under the PolyForm Noncommercial License 1.0.0, provided the platform is used solely for SDBOR’s internal, noncommercial purposes.

O erors are responsible for evaluating and complying with all licensing terms applicable to their proposed solution. SDBOR expects vendors to identify and address any licensing requirements associated with their proposed implementation approach.

Could SDBOR provide additional information regarding the current status of the prebuilt AWS landing zone, including existing account structures, networking, security controls, logging, infrastructure-as-code tools, and remaining implementation gaps?

SDBOR intends to establish the AWS landing zone and foundational cloud services necessary to support Phase 1 deployment. While planning and design activities have occurred, the environment is not yet fully implemented. The selected vendor will be expected to review requirements, validate architecture, recommend improvements, and assist with implementation activities necessary to support deployment of the platform.

Environment-specific technical details and implementation priorities will be provided during project initiation.

Which AI models and model providers are currently included or approved within the

Boise State baseline, and may the selected partner recommend additional models during Phase 1?

The Boise State platform supports multi-model architecture. Vendors may recommend additional models and providers as part of their implementation approach. SDBOR anticipates retaining governance authority regarding approved model availability.

Please clarify whether SDBOR expects prompt and response logging to include complete interaction content or only metadata, particularly where FERPA, HIPAA, GLBA, research, or confidential institutional information may be involved.

SDBOR has not finalized all logging and retention requirements. The platform should support configurable logging capabilities su icient to support operational, governance, compliance, and security requirements. Vendors should describe available options and associated recommendations.

What level of configuration will be considered acceptable within Phase 1 without being classified as a prohibited custom extension or net-new platform capability?

SDBOR anticipates reasonable configuration, integration, branding, governance, identity, security, and operational changes necessary to deploy the platform within the SDBOR environment. Significant redevelopment of core platform functionality is not the primary objective of Phase 1 and should be clearly identified if proposed.

Has SDBOR established an anticipated budget range or not-to-exceed amount for

Phase 1 implementation?

SDBOR has not published a budget or not-to-exceed amount for this solicitation.

Does SDBOR anticipate awarding future enhancement phases to the Phase 1 partner, or will future phases be subject to separate competitive procurements?

Future phases, if pursued, will be evaluated in accordance with applicable procurement requirements and project needs. No commitment regarding future work is implied by this solicitation.

Are specific security certifications required, such as SOC 2 Type II, ISO 27001, or

StateRAMP?

No specific certification requirement has been established. Vendors should identify relevant security certifications, assessments, and security practices that support their proposed solution and services.

Vendor C:

1. Business Objectives: Besides the objectives outlined in the RFP, what are the primary business drivers and expected outcomes for implementing the SDBOR Enterprise AI Platform?

In addition to the objectives identified within the RFP, SDBOR seeks to establish a secure, scalable, and governed AI platform that supports institution-specific experiences while maintaining centralized oversight, operational ownership, and future extensibility.

2. Current Environment: Can SDBOR provide an overview of the current IT and cloud landscape, including the AWS Landing Zone architecture, Microsoft Entra ID environment, security tools, and any existing AI-related infrastructure?

SDBOR currently operates multiple Microsoft Entra ID environments across participating institutions and supports enterprise collaboration through existing federation and governance processes. SDBOR is planning the AWS landing zone and foundational cloud services that will support the project, but the environment has not yet been fully implemented. Additional environment details, architecture decisions, and implementation priorities will be provided during project initiation.

3. Boise State AI Platform: Will SDBOR provide the Boise State AgentCore Public Stack source code, deployment documentation, architecture diagrams, and implementation guides at project kicko ? Has the reference implementation been customized in any way?

O erors should utilize the publicly available Boise State AgentCore Public Stack repository and documentation. SDBOR has not materially modified the referenced baseline platform.

4. Current & Future Architecture: Can SDBOR share the current-state and target-state architecture diagrams, including any planned integrations beyond those identified in the RFP?

The RFP and accompanying materials identify the current expectations for Phase 1. Future architecture decisions, integrations, and enhancements will continue to evolve through governance and implementation activities.

5. Customizations & Integrations: Are there any existing customizations, APIs, interfaces, or enterprise integrations (e.g., Banner, D2L, Microsoft 365, data warehouse platforms) that should be considered during Phase 1, or are these strictly planned for future phases?

Phase 1 is primarily focused on deployment, governance, identity integration, institutional administration, security integration, and operational readiness. Integrations with systems such as Banner, D2L, Microsoft 365, data warehouse platforms, and other enterprise applications are generally anticipated for future phases and are not a primary objective of Phase 1.

6. Hosting & Infrastructure: Will the platform be deployed entirely within the existing AWS environment provided by SDBOR, and will all required AWS accounts, networking, security services, and administrative access be available before project kicko ?

The platform will be deployed within an SDBOR-owned AWS environment. SDBOR intends to establish the AWS landing zone and foundational cloud services required to support implementation. Vendors should assume collaboration with SDBOR and AWS may be necessary to finalize and implement components of the environment required for deployment. Environment readiness activities will be prioritized during project initiation.

7. Support & Governance: Can SDBOR share the current support structure for AWS, Identity, Security, and Infrastructure teams, and what level of involvement is expected from these teams during implementation and transition?

SDBOR personnel responsible for infrastructure, identity, security, and operations are expected to actively participate throughout implementation and transition activities. RIS maintains dedicated teams supporting identity and access management, infrastructure, security operations, and enterprise systems administration, and anticipates providing significant subject matter expertise and implementation support in these areas.

Governance ownership will remain with SDBOR.

8. Implementation Approach: Is SDBOR intending to award this project to a single implementation partner, or is there a possibility of multiple vendors supporting di erent workstreams?

SDBOR anticipates selecting a primary implementation partner for the Phase 1 scope identified in the RFP. SDBOR reserves the right to utilize other resources, including AWS, institutional personnel, or additional service providers where appropriate to support project objectives.

9. Incumbent Information: Is this a new initiative or is there an incumbent implementation partner? If applicable, can you share the incumbent's name and the primary reasons for issuing this RFP?

This is a new initiative. SDBOR does not currently have an incumbent implementation partner responsible for deployment of the Boise State AgentCore Public Stack, Phase 1 implementation activities, or AWS implementation services associated with this project.

10. Delivery Model: Is a hybrid delivery model with US-based project leadership and remote/o shore technical resources acceptable for this engagement? Are there any minimum onsite presence, residency, citizenship, security clearance, or travel requirements for the project team? Additionally, is a fully remote US-based delivery model acceptable, and are o shore resources permitted to support the project?

SDBOR does not prescribe a specific delivery model. O erors should clearly identify proposed sta ing locations, project governance, communication processes, and any assumptions regarding remote, onsite, or o shore resources. SDBOR reserves the right to evaluate sta ing and delivery approaches as part of the overall proposal evaluation process.

11. Proposal Sta ing: Should vendors submit complete resumes or just profile summaries for proposed key personnel who will actually work on the project, or sample resumes are allowed? Is it acceptable to propose representative/sample resumes at the proposal stage?

O erors should provide su icient information to demonstrate the qualifications and experience of proposed project personnel. Profile summaries are acceptable provided they adequately describe relevant experience, certifications, skills, and anticipated project responsibilities.

12. Future Roadmap: Beyond the future phases identified in the RFP, are there any major AI, cloud, or digital transformation initiatives planned that the selected partner should consider while designing the Phase 1 solution?

SDBOR continues to evaluate opportunities related to artificial intelligence, cloud services, automation, analytics, and digital transformation across participating institutions. Future initiatives will be prioritized through governance processes and institutional needs.

O erors should design Phase 1 with scalability, extensibility, and future integration opportunities in mind.

13. Business Registration: Are there any State of South Dakota business registration, licensing, or vendor registration requirements that must be completed prior to contract award or project commencement? Is it mandatory to be registered in the State to bid on this RFP? Can we register with State after award and before the work commences?

O erors are responsible for complying with all applicable State of South Dakota procurement, registration, licensing, tax, and contracting requirements. Additional information regarding vendor requirements is available through the State procurement process and resulting contract documentation.

14. Supplier Diversity: Are there any mandatory or preferred participation requirements for MBE, WBE, DBE, VBE, or other supplier diversity certifications?

Does SDBOR provide any evaluation preference for local or diverse businesses?

No specific supplier diversity participation requirements or evaluation preferences have been established for this solicitation. Proposals will be evaluated in accordance with the criteria identified in the RFP.

15. Pricing Structure: Does SDBOR have a preferred pricing model (Fixed Fee, Time & Materials, or Hybrid), or will all pricing approaches be evaluated equally?

SDBOR will evaluate pricing approaches based on overall value, scope alignment, assumptions, risk allocation, completeness, and ability to successfully deliver the project objectives. O erors may propose the pricing structure they believe is most appropriate for the engagement.

16. Cost Proposal: Should travel, project management, documentation, training, knowledge transfer, and post-go-live hypercare be included within the Phase 1 pricing, or may they be priced separately? Is there a preferred payment milestone structure?

O erors should clearly identify all costs, assumptions, exclusions, optional services, and pricing components associated with their proposed approach. SDBOR prefers pricing that provides su icient transparency to evaluate the complete cost of implementation and transition to operational ownership.

17. Evaluation Priorities: Beyond the published evaluation criteria, are there any specific factors (such as AWS implementation experience, higher education experience, knowledge transfer, or implementation methodology) that SDBOR considers particularly important when selecting the implementation partner?

Evaluation will be conducted in accordance with the criteria identified in the RFP. SDBOR values experience with AWS-based deployments, higher education environments, security and governance requirements, knowledge transfer, operational readiness, and the ability to successfully implement the Boise State AgentCore Public Stack within the proposed timeline.

18. Budget: Is there an estimated budget or funding range established for Phase 1 implementation that vendors should consider while preparing their cost proposal?

SDBOR has not published a budget or not-to-exceed amount for this solicitation. O erors should propose an approach and pricing structure that they believe provides the best overall value for successful delivery of the Phase 1 objectives.

19. Solution Sizing: Can SDBOR provide the expected implementation scale for Phase 1, including the approximate number of students, faculty, sta , researchers, active/concurrent users, institutional administrators, AI assistants, prompt libraries, knowledge repositories, and the estimated volume/size of documents to be ingested?

The platform is being designed to support all participating SDBOR institutions, representing more than 36,000 students across the system, as well as faculty, sta , researchers, and administrators. SDBOR has not established final adoption, concurrency, assistant, repository, or document ingestion estimates for Phase 1 and anticipates adoption will increase over time following deployment. O erors should describe relevant assumptions, sizing considerations, scalability characteristics, and capacity planning approaches associated with their proposed solution.

20. AWS Environment Scope: Can SDBOR clarify how many AWS accounts and environments (Development, Test, UAT, Production, etc.) are included in Phase 1?

Additionally, is the AWS Landing Zone already fully implemented, or is the selected partner expected to perform remediation and additional Landing Zone configuration as part of this engagement?

O erors should assume separate development, testing, and production environments at a minimum. Additional environments may be recommended by the selected vendor. The AWS landing zone is not yet fully implemented and is still being set up by RIS. The selected partner should expect to review requirements, validate the proposed architecture, recommend improvements, and assist with reasonable landing zone and cloud configuration activities necessary to support successful deployment of the Phase 1 solution.

21. Configuration Scope: Will all seven institutions follow a common configuration, security model, and governance framework, or will institution-specific configurations, workflows, AI models, security policies, or administrative controls be required beyond branding?

SDBOR anticipates a shared platform architecture, common governance framework, and common security foundation across participating institutions while supporting institution-specific branding, delegated administration, content management, and operational flexibility where appropriate. Additional governance and administrative decisions will be refined during implementation.

22. Testing Responsibilities: Can SDBOR clarify the vendor's responsibilities for testing, including functional, integration, performance, security, accessibility, user acceptance testing (UAT), and production cutover support?

The selected vendor should expect to support implementation testing activities including functional validation, integration testing, security review support, accessibility review support, performance validation, documentation of test results, issue remediation, deployment readiness, and assistance with user acceptance testing. Final testing responsibilities will be confirmed during project initiation.

23. Commercial Assumptions & Change Management: For vendors proposing a Fixed Fee model, should pricing assume that the scope and implementation assumptions remain fixed throughout Phase 1, with any additional requirements or AWS Landing Zone remediation managed through a formal change request process?

O erors should clearly identify assumptions, dependencies, exclusions, risks, and change management processes associated with their proposed pricing model. Material deviations from agreed-upon scope, assumptions, or requirements would generally be expected to follow an appropriate change management process.

24. Existing Data & Migration: Does Phase 1 include migration of any existing AI assistants, prompt libraries, knowledge repositories, user content, or historical data into the new platform? If so, can SDBOR provide an estimate of the migration scope?

SDBOR does not currently anticipate large-scale migration of existing AI assistants, prompt libraries, knowledge repositories, or historical platform data as part of Phase 1. The primary focus is deployment of the baseline platform, governance, identity integration, institutional administration, security integration, and operational readiness. O erors may identify migration considerations or future opportunities as part of their proposed approach.

25. Project Timeline: The RFP targets completion of Phase 1 by mid-September 2026.

Has SDBOR already established a detailed implementation schedule with key milestones, resource availability, and institutional participation, or is the selected partner expected to develop the project plan following contract award?

SDBOR has established a target timeline and high-level project objectives for Phase 1. The selected vendor will be expected to collaborate with SDBOR to develop the detailed implementation plan, milestones, dependencies, and resource assignments following contract award. RIS personnel supporting infrastructure, identity, security, and operations will actively participate throughout implementation.

Vendor D:

1. Shared Prompt Libraries and Reusable Templates The Boise State agentcore-public-stack baseline appears to support assistant-specific instructions and conversation starters, but it does not appear to include a separate first-class feature for centralized shared prompt libraries or reusable prompt templates with dedicated administrative controls.

For Phase 1, our assumption is that this requirement would be satisfied through the baseline assistant-management capabilities already present in the Boise State platform, and that a more formal shared prompt library/template management capability would be better addressed as a Phase 2 enhancement.

Can SDBOR please confirm whether this assumption is acceptable, or whether SDBOR expects a centralized shared prompt library and reusable template administration feature to be delivered as part of Phase 1?

For Phase 1, SDBOR anticipates utilizing the assistant management, configuration, and sharing capabilities included within the baseline Boise State AgentCore Public Stack. A dedicated centralized prompt library or template management capability is not currently required for Phase 1 provided the baseline platform supports practical assistant configuration, reuse, and administrative management. Vendors may identify potential enhancements for future phases.

2. Security, Compliance, and Control Ownership Our assumption is that, for Phase 1, the implementation partner is responsible for delivering baseline technical security capabilities and configurable controls within the Boise State agentcore-public-stack architecture, such as encryption in transit and at rest, secure administrative access, logging, access control, and data-isolation enforcement, while SDBOR remains responsible for policy definition, data classification, control operation, institutional usage rules, retention decisions, and determination of whether the deployed platform is compliant for specific regulated use cases.

Can SDBOR please confirm whether this allocation of responsibilities is correct, and whether there are any specific mandatory Phase 1 compliance controls, logging requirements, retention requirements, or prohibited data/use cases that must be explicitly implemented at go-live?

Generally, yes. SDBOR expects the implementation partner to configure and implement appropriate technical security capabilities, administrative controls, logging capabilities, access controls, and platform configuration options available within the proposed architecture. SDBOR and participating institutions will retain responsibility for governance, policy development, data classification, retention decisions, acceptable use determinations, and compliance oversight. Specific operational, logging, retention, and governance requirements will continue to be refined during implementation.

3. Logical Separation of Institutional Data Can SDBOR clarify whether “logical separation of institutional data” is expected to be enforced through shared-platform tenant-aware access controls, or whether any data domains require stronger physical or account-level separation in Phase 1?

Phase 1 is expected to leverage logical separation mechanisms within a shared platform architecture, including role-based access controls, delegated administration, content segregation, and institution-specific administrative visibility. SDBOR does not anticipate institution-specific physical infrastructure separation requirements as part of Phase 1.

Vendors may recommend alternative approaches where they provide meaningful security, operational, or governance benefits.

4. Sentinel and Red Canary Integration Scope What specific Sentinel and Red Canary integration outcomes are expected in Phase 1: raw log forwarding, normalized detections, alert rules, dashboards, or incident workflows?

SDBOR currently utilizes Microsoft Sentinel and Red Canary as part of its existing security operations program. The platform should provide logging, monitoring, and security visibility capabilities su icient to support integration with existing security operations processes.

RIS security personnel will provide subject matter expertise and support for monitoring and integration activities during implementation. Vendors should describe available logging, alerting, observability, and event forwarding capabilities along with any recommendations.

Specific integration requirements and priorities will be determined during implementation planning.

5. What is the overall budget of phase1 and for overall project.

SDBOR has not published a budget, not-to-exceed amount, or overall program budget associated with this solicitation. O erors should propose the approach, scope, sta ing model, and pricing structure they believe will successfully deliver the Phase 1 objectives and provide the best overall value.

Vendor E:

1. AWS Landing Zone Can additional technical documentation (architecture diagrams, account structure, current guardrail configuration) for the prebuilt landing zone be provided to o erors prior to the proposal due date, or will this be shared only with the selected o eror?

SDBOR does not anticipate providing additional AWS landing zone documentation to o erors prior to award. Environment-specific architecture, configuration, and implementation details will be made available to the selected vendor during project initiation. The AWS landing zone and supporting cloud services are currently being planned and configured, and the selected vendor should expect to participate in architecture validation, implementation planning, and related activities.

2. Access to the Boise State AI Platform (AgentCore Public Stack) Will o erors have access to technical documentation, source code, or a demonstration environment for the AgentCore Public Stack in order to evaluate its architecture prior to submitting the technical and cost proposal?

O erors should utilize the publicly available Boise State AgentCore Public Stack repository and associated documentation when preparing proposals. SDBOR does not anticipate providing access to additional source code, technical documentation, or demonstration environments beyond what is publicly available.

3. Federated Identity Can you confirm the current version/configuration of Microsoft Entra ID and the existing SSO patterns within RIS? Are there institution-specific MFA requirements that di er across the seven institutions?

SDBOR currently operates multiple Microsoft Entra ID environments across participating institutions and supports enterprise collaboration through established federation and single sign-on processes. Multi-factor authentication is currently standardized through Duo. SDBOR anticipates migration to Microsoft Authenticator as part of its broader identity strategy. The selected vendor should assume a multi-institution identity model with delegated institutional administration and systemwide governance. RIS identity personnel will actively participate in identity-related planning and integration activities.

4. Domain Strategy Does SDBOR have a defined preference between independent institutional domains versus a centralized approach, or is the o eror expected to propose and justify a recommendation?

SDBOR prefers a distinct branded experience for each participating institution while maintaining a shared technology foundation and centralized governance model. However, SDBOR is open to alternative approaches, including a shared branded experience, where they provide meaningful benefits in simplicity, maintainability, operational e iciency, or cost. O erors should recommend the domain and URL strategy they believe best supports these objectives.

5. Phase 1 Scope vs. Customization Section 3.3 indicates that implementation should avoid custom extensions beyond the agreed Phase 1 scope. Could you clarify the process for requesting and approving any minor configuration adjustments that arise during implementation?

SDBOR anticipates reasonable implementation, configuration, branding, governance, identity, operational, and security-related adjustments will occur as part of deployment.

Material changes to scope, functionality, timeline, or project assumptions would be expected to follow an appropriate change management process established during project initiation.

6. Integration with Microsoft Sentinel and Red Canary Will RIS provide the necessary credentials/API access for log integration, or is the o eror expected to fully coordinate this with RIS security teams?

RIS security personnel will provide subject matter expertise and support for security monitoring and integration activities during implementation. The platform should provide logging, monitoring, and security visibility capabilities su icient to support existing security operations processes. Specific integration requirements and responsibilities will be determined during implementation planning.

7. Platform Consumption Costs Confirming Section 7.5: should o erors include any indicative estimate of AWS/AI model consumption costs for informational purposes only, or are these entirely excluded from the evaluation process?

AWS infrastructure, AI model consumption, and other platform operating costs are the responsibility of SDBOR and are not part of the implementation services evaluation.

O erors may provide informational estimates, assumptions, or recommendations regarding anticipated platform consumption costs if they believe such information would be beneficial.

8. Contract Negotiation Timeline Given that the award decision is anticipated for July 31, 2026, and the Phase 1 completion target is mid-September 2026, is there flexibility in the start timeline should contract negotiation extend beyond what is currently anticipated?

The Phase 1 timeline reflects SDBOR's current objectives and desired implementation schedule. O erors should identify any assumptions, dependencies, risks, or timeline considerations associated with their proposed approach. SDBOR will work collaboratively with the selected vendor to establish an achievable implementation plan following contract award and contract execution.