Credential Engine Releases RFP to Scale CTDL xTRA Platform

Credential Engine released a Request for Proposals (RFP) seeking an experienced partner to help scale CTDL xTRA, an open source, AI-assisted platform developed by Credential Engine to transform publicly available web content into structured Credential Transparency Description Language (CTDL) data in the Credential Registry.

The selected partner will collaborate closely with Credential Engine’s engineering team to evolve CTDL xTRA into a scalable, production-ready platform that improves the extraction, transformation, validation, and publication of credential information. The project will focus on advancing AI- and machine learning-assisted workflows while maintaining Credential Engine’s commitment to open source development and interoperable data standards.

Credential Engine is looking for a collaborative technical partner with expertise in AI/ML-assisted extraction systems, semantic technologies, linked open data, workflow orchestration, and scalable platform architecture. The work will build on CTDL xTRA’s existing capabilities, helping expand support for additional CTDL classes, improve extraction quality and efficiency, and strengthen the platform for long-term sustainability.

The RFP welcomes responses from qualified organizations with experience developing production-ready AI solutions and open source technologies that support education, workforce, and data interoperability initiatives.

All responses and questions are due by August 14th, 2026. Following an initial review, selected respondents will be invited to participate in technical discussions to further refine implementation priorities and project scope.

Organizations interested in applying are encouraged to review the full RFP for project requirements, response instructions, and evaluation criteria.

Review the RFP and submit a proposal today: CTDL xTRA RFP for Scaling and Sustainability

RFP Q&A

1. May the required professional references include successful projects completed by the proposed key personnel before they became represented through Hybrion, provided that the relevant client contacts can verify their contributions?
   • Yes
2. Is the selected consultant expected to provide deep hands-on .NET and Azure implementation capacity, or will Credential Engine’s internal engineering team continue to lead those platform-integration components while the consultant focuses primarily on AI/LLM extraction, evaluation and workflow improvements?
   • Credential Engine’s engineering team will lead and be primarily responsible for the Azure integration with our Registry accounts and publishing platform. The latter part of your question is correct; primarily focus on sustainable and scalable AI/LLM extraction, evaluation, and workflow improvement.
3. The RFP emphasizes AI/ML-assisted extraction. Could you please confirm whether respondents are expected to disclose details of AI usage, such as model providers, sustainability strategies, reproducibility controls, and related implementation approaches, as part of the proposal?
   • The proposal does ask for some of this information so we can understand how you would approach the project. We currently use the OpenAI API for transformation and have had good results, and a branch in the codebase, for agentic crawling via Anthropic API. We are looking for sustainable models and are open to different approaches.
4. Additionally, is subcontracting or engaging specialized implementation partners permitted under this RFP?
   • Possibly, though we prefer to maintain a direct relationship, and communications will need to occur during U.S. business hours.
5. Could you please share the expected payment terms for this engagement?
   • We expect the payment terms to be based on the completion of agreed-upon deliverables.
6. If available, could you also provide an indicative budget or approximate contract value for this opportunity?
   • We would like to see proposals that come in under $500,000. As mentioned in the RFP, the contractor will work directly with a project lead engineer on our team, our Director of Engineering, and other Credential Engine team members including our product owner. This will be a division of labor with our team handling most of the integration with our platform and directly contributing to the AI and evaluation layers.
7. For organizations outside the United States, is it mandatory to obtain insurance through US-licensed carriers? Alternatively, would coverage from internationally licensed carriers with strong credit ratings be acceptable?
   •  We do not require US-licensed carriers. Coverage from an internationally licensed carrier is acceptable provided the carrier maintains a minimum rating of A- from A.M. Best (or an equivalent rating from S&P or similar). We’d also want the policy to respond to claims arising in the US since the work will be performed for Credential Engine and we are a US-based organization.
8. What are the insurance requirements for bidders?
   • These are the coverage requirements:
     • Commercial General Liability: $1M per occurrence / $2M aggregate
     • Professional Liability / Errors & Omissions: $1M per occurrence / $1M aggregate
     • Cyber Liability / Technology E&O: $1M per occurrence
     • Workers’ Compensation: only required if you have employees performing work in the US, or as required by applicable law in your jurisdiction

     These are our target minimums. We’re open to discussing equivalent coverage if bidder’s standard policies are structured differently.

9. By when will the shortlisted candidates be invited for further discussions?
   • We anticipate inviting candidates to meet with the review team within 2 weeks of the submittal deadline.
10. Is there a target date for the selected vendor to start Phase 1 implementation?
    • We prefer to start in early September 2026.
11. For the Year 1 expansion into public PDF ingestion and OCR, should respondents assume college catalog PDFs (course, program, and credential content) are the priority corpus, or are there other document types you would want weighted in the first six months?
    • For Year 1, our priority is to expand beyond the current CTDL xTRA coverage of credentials, learning programs, courses, and competencies. While college catalogs and similar PDFs are an important source of information, we are not limiting the platform to higher education or .edu websites. We are looking for dependable extraction and transformation from a broad range of publicly available sources, including occupational licensing agencies, certification bodies, certificate issuers, workforce organizations, and other credential providers.We would also like to see expansion beyond the current CTDL classes to support additional classes such as those identified in the RFP (pages 12 to 13), including Support Service, Occupation, Job, Metric/Data Set Profile, Quality Assurance Action, and Assessment Profile. We welcome recommendations on prioritization and implementation approaches.
12.  On benchmarking and quality measurement: does Credential Engine have ground-truth datasets from the pilot implementations that the selected consultant would evaluate against, or should proposals plan for building the evaluation sets as part of the first 90 days?
    • Yes. We have datasets from pilot implementations and data that has been published to the Credential Registry that can serve as initial benchmarks. However, we expect the selected partner to establish a sustainable evaluation framework early in the project, including developing evaluation datasets, benchmarks, and ongoing quality-measurement processes. We anticipate this work will begin within the first 90 days.
13. Are you looking for proposals to come in under $500,000 for three years, or is that amount for the first year?
    • We are looking for cost-effective proposals. A total project cost under $500,000 over the three-year project period is preferred.  We anticipate an initial contract will be awarded to the selected partner for 1 year with options to extend based on outcomes.
14. Does Credential Engine have a preferred staffing approach? For example, are you open to one or more fractional resources?
    • We are open to fractional resources provided they are dependable, responsive, and able to meet the project’s collaboration and delivery expectations.
15. Working setup: What does the day-to-day collaboration with the assigned lead engineer look like in practice (repository access, environments, standups), and what level of access does the consultant get to the deployment environment for integration testing?
    • We do not anticipate daily meetings. We will establish a collaboration cadence that works for both teams and use GitHub, Slack, and shared documentation to coordinate work. Credential Engine will provide access to the GitHub repository and can provide access to a test environment as needed. It is unlikely that we will provide direct access to our Azure DevOps environment. Credential Engine’s engineering team will coordinate directly with the selected partner to establish deployment and testing procedures.
16. Target environment: The RFP lists Azure, Argo Workflows, and Keycloak, while the public ctdl-xTRA repository currently deploys to AWS EKS with GitHub Actions. Should respondents assume infrastructure migration into the broader Credential Engine stack is expected during this engagement?
    • Credential Engine’s engineering team will be responsible for deployments to Credential Engine environments. The Director of Engineering will determine any changes needed to the GitHub architecture to support integration with Credential Engine’s development and deployment environments.
17. Agentic workflows on the Anthropic API: Is the work referenced in the RFP the unmerged agentic crawling branch in the public repository, and would the selected partner build on that experiment or design the model-provider abstraction fresh?
    • The agentic MVP was published in the public repository under the feat/agentic-crawling branch.
18. Model flexibility: Where comparative evaluation shows an open-weight or self-hosted model meets the quality bar at lower cost, is there flexibility to use it alongside or in place of frontier providers?
    • Yes. We are open to sustainable and cost-effective options.
19. Benchmark data: Would the pilot implementation datasets mentioned in the Q&A be shared with the selected partner before the SOW is finalized, so the first 90 days evaluation framework can be scoped against real data?
    • Yes.
20. Contribution structure: Should all contributions land in the ctdl-xTRA repository itself, or are companion Apache 2.0 packages under the Credential Engine GitHub organization acceptable, for example, a standalone evaluation harness?
    • We are open to approaches that support an open source ecosystem.
21. Production-ready bar: What accuracy or precision-recall level does Credential Engine consider production-ready for the six-month Year 1 goal, and is that bar per CTDL class or per field?
    • Production readiness criteria will be established by the Director of Engineering in collaboration with the selected partner and the Credential Engine project team.
22. Source prioritization: For the Year 1 expansion into PDF ingestion and OCR, which document sources and states should be prioritized first?
    • Credential Engine is currently working with five states and will share participating states as those engagements are formalized. Examples of PDF document sources include school and college catalogs containing programs and courses, as well as competency frameworks. Our team is also conducting landscape analyses within participating states to identify additional document sources, including PDFs.
23. Gold-data validation: Who validates gold and ground-truth datasets (Credential Engine staff, pilot partners, or the consultant), and is human validation capacity available on Credential Engine’s side?
    • Validation of gold and ground-truth datasets will be led by Credential Engine in collaboration with participating partners and the selected consultant. Credential Engine will provide human validation resources while working with project partners.
24.  Are current extraction quality measurements available by CTDL class?
    • Existing extraction workflows function at varying levels of maturity, automation, and accuracy across CTDL classes and public information sources.Credential Engine has pilot datasets, published CTDL data in the Credential Registry, extraction results, and operational information that can assist the selected partner in assessing current performance. One of the early implementation activities will be establishing consistent class-level and property-level evaluation metrics to support prioritization, benchmarking, and continuous improvement.
25. What is the current extraction volume, and what is the Year 1 target for records published to the Credential Registry?
    • Current CTDL xTRA activity reflects pilot implementations, testing, and ongoing development rather than sustained production operations.Credential Engine has established preliminary planning estimates for Year 1 that include publishing approximately 326,000 additional credential records across multiple credential types. This estimate reflects Credential Engine’s current priorities for expanding credential coverage through CTDL xTRA.For additional CTDL classes identified in the RFP, including learning opportunities, competencies, support services, assessments, occupations, transfer value profiles, and other planned classes, Credential Engine is conducting landscape analysis with participating states and partners to establish realistic publication estimates and implementation priorities. Respondents should propose approaches that can efficiently scale as additional CTDL classes and publicly available information sources are prioritized. 
26. Beyond the public repository, are there private components a selected respondent would receive access to, such as production deployment configuration, prompt or recipe libraries, evaluation harnesses, or historical extraction logs?
    • No. The public GitHub repository accurately represents the current CTDL xTRA codebase. Credential Engine does not maintain separate private prompt libraries, recipe libraries, evaluation harnesses, or historical extraction repositories beyond the project materials described in the RFP. As noted in the Q&A, Credential Engine can provide access to a test environment, sample datasets, project documentation, and other resources necessary to support the implementation engagement. The selected partner will be provided Credential Registry API keys, as appropriate, to support development, testing, and integration activities. Credential Engine engineering staff will coordinate access to development resources appropriate to the agreed-upon scope of work.
27.  What is the current monthly AI and LLM operating spend for CTDL xTRA, and is there a cost reduction target for Year 1?
    • Current AI and related operating costs, including IP rotation services, have averaged approximately $290 per month. These costs have been substantially offset through development credits provided by Anthropic and OpenAI. Current usage reflects software development, testing, pilot implementations, and limited extraction activities and is not representative of anticipated production-scale operations. This figure does not include the underlying virtual machine, application, or database hosting costs associated with the CTDL xTRA platform.Credential Engine’s objective is to achieve sustainable, cost-effective AI and machine learning operations as CTDL xTRA scales. Long-term sustainability depends on an operating model with low recurring operational costs that can support broad adoption. Respondents should recommend approaches that minimize recurring operational costs while maintaining high extraction quality, reproducibility, maintainability, and scalability.
28.  What role does Credential Engine expect Learning Tapestry to hold going forward?
    • Learning Tapestry partnered with Credential Engine to develop the initial CTDL xTRA platform and will continue to be part of the implementation team. Their work will include supporting ongoing extraction requests for existing CTDL classes, expanding support for additional CTDL classes, enhancing the CTDL xTRA user interface, implementing integration-related code changes, and participating in validation and testing activities. The engagement described in this RFP will be led and managed by Credential Engine. The selected implementation partner will work directly with Credential Engine’s engineering team and project leadership to implement the AI and machine learning capabilities described in the RFP. Credential Engine will coordinate responsibilities among its staff, Learning Tapestry, and the selected partner to ensure the work is complementary, follows agreed-upon technical direction, and avoids duplication of effort.
29. Is CTDL xTRA currently deployed on the Azure, Azure Blob Storage, Kubernetes, Argo Workflows, and Keycloak stack described as the engineering environment, or would migration onto that stack form part of this engagement?
    • The current CTDL xTRA application is deployed as a stand-alone application and database in AWS. As noted in the RFP, Credential Engine’s target engineering environment is Microsoft Azure, and Credential Engine engineering staff will lead platform architecture, infrastructure, deployment, and integration with Credential Engine environments. The engineering environment described in the RFP reflects Credential Engine’s target platform architecture. The selected implementation partner should assume that Credential Engine engineering staff will lead infrastructure implementation and deployment, while the selected partner focuses primarily on AI and machine learning capabilities, extraction workflows, evaluation frameworks, and implementation of the agreed-upon technical enhancements.
30.  Are there constraints on self-hosted or open-weight model deployment, such as available GPU capacity, Azure region requirements, or internal procurement approval?
    • Credential Engine is open to sustainable and cost-effective approaches, including commercial APIs, open-weight models, and self-hosted deployments where appropriate. Credential Engine’s production environment is hosted in Microsoft Azure using primarily U.S. regions. If respondents recommend self-hosted or open-weight models, any additional Azure resources, including GPU-enabled infrastructure, would be considered as part of the proposed implementation approach. Respondents should clearly identify the infrastructure, operational, security, staffing, and cost assumptions associated with their recommendation. Infrastructure decisions will be evaluated collaboratively based on technical feasibility, operational sustainability, security, maintainability, cost, and alignment with Credential Engine’s long-term objectives.
31. Is there a deadline for submitting questions, and where will the posted questions and responses be published?
    • While questions may be submitted at any time before the proposal deadline, Credential Engine strongly prefers that all questions be submitted no later than Tuesday, August 11, 2026, to allow sufficient time to prepare and post responses for the benefit of all respondents. Questions should be submitted electronically to Jeanne Kitchens, CTSO, Credential Engine. Questions and responses will be posted on the CTDL xTRA RFP web page Credential Engine Releases RFP to Scale CTDL xTRA Platform. 
32. What timeline does Credential Engine anticipate for the technical discussions and for a selection decision following the August 14 response deadline?
    • Credential Engine intends to begin proposal review immediately following the August 14 submission deadline and expects to move quickly through proposal evaluation and technical discussions.Credential Engine’s goal is to enter into contract negotiations by September 1, 2026, execute a contract as soon as practical thereafter, and begin the implementation engagement during the week of September 14, 2026. These dates are anticipated and may be adjusted based on the proposal review process and contract negotiations.
33. Are there format preferences beyond Microsoft Word, Google Doc, or PDF, such as a page limit, or a preference for optional supporting materials to be embedded in the response rather than supplied as separate files?
    • There is no page limit beyond the guidance provided in the RFP. The recommended word counts are intended to encourage concise, well-organized responses rather than establish minimum or maximum lengths.Credential Engine encourages respondents to organize proposals in a clear and concise manner that makes them easy for reviewers to evaluate. Supporting materials may be included within the proposal or submitted as separate attachments. Proposals and supporting materials should be provided in commonly used, easy-to-read, and readily accessible document formats, such as Microsoft Word, Google Docs, PDF, or spreadsheets, as appropriate.
34. The RFP mentions public GitHub repositories and contributions to the open source community. Could you please confirm whether these are mandatory qualification requirements? If an applicant does not meet this criterion, would it result in disqualification?
    • No. Public GitHub repositories and prior open source contributions are not mandatory qualification requirements, and the absence of these would not automatically disqualify a respondent.As reflected in the RFP, respondents are asked to provide relevant GitHub repositories and open source contributions where applicable. Credential Engine is primarily interested in identifying organizations with the technical expertise, implementation experience, and collaborative approach needed to successfully support CTDL xTRA.
      However, CTDL xTRA is an open source platform, and all new capabilities developed through this engagement are expected to align with Credential Engine’s open source development approach, GitHub-based collaboration workflows, and Apache-licensed codebase. Respondents should therefore demonstrate their ability and willingness to work effectively within this model, regardless of whether they have prior public GitHub contributions to provide.
35. The RFP also requests two U.S. references. Could you please clarify whether this is a mandatory requirement and whether it is considered a disqualifying criterion if not met?
    • The RFP requests at least two professional references for successful projects. Verifiable references from regions outside the U.S. are acceptable. As noted in the RFP, because the engagement will involve ongoing collaboration with Credential Engine leadership and engineering staff, respondents should be able to support regular collaboration during U.S. business hours
36. Could you please clarify the purpose of the Data Library? Is it intended to store the extracted and transformed data in the standard CTDL-aligned format that is ready for publication to the Credential Registry?
    • Yes. The Data Library allows Credential Engine users to access an organization-based archive of CTDL xTRA transformations. It provides access to each extraction and allows users to download the resulting CSV files. These CSV files are expected to be publication-ready and aligned with the applicable CTDL bulk upload format for publication to the Credential Registry. Publication to the Credential Registry is a separate step.
37. For the “foundational self-service and partner enablement capabilities” planned for Year 1, do you envision external institutions or partner organizations accessing CTDL xTRA directly, or will CTDL xTRA continue to be primarily operated by Credential Engine users?
    • We anticipate supporting both models. Credential Engine expects to offer services that include managing extraction and transformation activities on behalf of partners, while also enabling self-service access for partners that want to manage their own workflows. Year 1 will focus on establishing the foundational capabilities needed to support this combined service and self-service model.
      
38. Could you please identify the key limitations you have observed in the current pilot and AI-assisted extraction workflows, such as extraction accuracy, consistency, processing efficiency, scalability, or human review effort? Understanding the primary pain points would help us address them more specifically in our proposed approach.
    • This is partially addressed in existing Q&A regarding extraction quality, evaluation, scalability, and operating costs. Recent work has demonstrated very good extraction and transformation accuracy. A key challenge is consistently navigating diverse source structures, particularly catalogs where relevant information may be distributed across multiple pages and links.
      
      Work to date has also largely focused on extracting one CTDL class at a time. We want to improve the efficiency of extracting related data across multiple classes and appropriately linking that data.
      
      Scalability has not yet been a significant pain point, but as usage increases, we need to ensure that accuracy and cost scale sustainably. As noted in the existing Q&A, establishing consistent evaluation and benchmarking will be an important part of the engagement.
39. What is the primary indicator of success for this partnership after 12 months? For example, is it: a) CTDL xTRA extracts data for all new CTDL classes at an acceptable cost; b) the internal Credential Engine engineering team can independently modify any part of the AI/ML pipeline; or c) a specific number of new credentials are published to the Registry?
    •  No single one of these measures defines success by itself. The primary Year 1 objective is to establish CTDL xTRA as a substantially more production-ready, scalable, sustainable, and maintainable platform capable of increasing the availability of high-quality CTDL linked open data. Success should therefore include measurable improvements in extraction quality, semantic accuracy, reproducibility, operational efficiency, cost sustainability, CTDL class and relationship coverage, and integration with Credential Engine publishing workflows.
      Knowledge transfer and maintainability are also important. The engagement is specifically designed so that Credential Engine’s engineering team retains the ability to maintain and continue evolving the platform rather than becoming dependent on the selected consultant. Credential Engine has a preliminary planning estimate of approximately 326,000 additional credential records during Year 1, but publication volume is not intended to be the sole measure of technical success. Similarly, the RFP identifies multiple priority CTDL classes, but it does not require every identified class to reach the same level of production maturity during the first year. The detailed Year 1 success measures and acceptance criteria will be established collaboratively as implementation priorities and the statement of work are finalized
40. For the automated re-extraction and “data currency” workflows, how frequently do you expect data to be updated? What is the primary trigger for a re-extraction? For example, a timed schedule or a manual flag by a user?
    •  Credential Engine does not expect a single re-extraction frequency or trigger to be appropriate for all CTDL classes and public sources. Update cycles vary depending on the type of information, the source, and the publishing practices of the organization.
      For example, schools typically publish updated catalogs annually and may publish amendments as programs, courses, or other offerings change. Some institutions update their catalogs more frequently, such as monthly. Other public sources may have different update cycles.

      The RFP calls for scalable extraction management and scheduling, automated re-extraction, relationship-aware updates, and data currency workflows. We anticipate that the platform should support multiple approaches to triggering re-extraction, including scheduled re-extraction, manual initiation, and, where practical, automated detection of meaningful changes to source information

41. For Year 1 experimentation, do you have a specific non-English source, such as a German university catalogue, and a specific target CTDL class in mind for the first test, or is the goal simply to create an abstract, configurable “language pack” system?
    •  Credential Engine has not designated a specific language, international source, or CTDL class for the initial multilingual experiment.
      Year 1 calls for initial multilingual and international extraction experimentation, with broader multilingual and international capabilities anticipated in later phases.

      We welcome recommendations for an approach that allows meaningful experimentation with representative non-English sources while establishing an architecture that can expand to additional languages and qualification systems without requiring a separate hard-coded implementation for each language

42. The RFP lists “self-hosted and open-weight models” as a priority. In Year 1, is the objective to support multiple model providers (OpenAI, Anthropic, etc.) in a production, fallback capacity, or is the primary goal to create the abstraction layer that makes this easy to implement later?
    •  Credential Engine’s priority is to establish a flexible model orchestration and provider-abstraction architecture that avoids unnecessary dependence on a single provider and allows models to be evaluated and incorporated with minimal changes to extraction workflows.
      The RFP also calls for comparative evaluation of commercial APIs, open-weight models, self-hosted approaches, smaller language models, and future providers.

      A production active-active or automatic provider failover capability is not specifically established as a Year 1 requirement. Respondents may recommend such functionality if it provides sufficient operational value, but the foundational requirement is an architecture that makes provider selection, evaluation, substitution, and future expansion practical and maintainable.

43. The RFP mentions “future multi-tenant deployment” and “role-based access control.” For this engagement, should we design the architecture assuming a single-tenant Credential Engine use case with flexibility for multi-tenancy later, or should we treat multi-tenancy as a core requirement for the initial architecture?
    •  The architecture developed during this engagement should avoid design decisions that would prevent or make future multi-tenant deployment unnecessarily difficult.
      The RFP describes architecture that supports future multi-tenant deployment, rather than requiring a fully implemented production multi-tenant platform as an initial six-month deliverable.

      At the same time, Year 1 includes foundational self-service and partner enablement capabilities, and Credential Engine anticipates supporting both Credential Engine-managed services and direct partner use. Respondents should therefore design with organizational separation, authentication, authorization, role-based access, and future multi-tenancy in mind while recommending an incremental implementation sequence appropriate to Year 1 priorities.

44. For the new CTDL classes, such as Occupation, do we already have a corresponding Bulk Upload Template defined for the Credential Registry, or does building the CTDL xTRA extraction pipeline also require us to design the new CSV output structure and Registry import logic?
    •  The RFP provides example Credential Registry bulk upload templates for the priority expansion classes, including Support Service, Occupation, Job, Metric/Data Set Profile, Action, and Assessment Profile. The selected consultant should therefore not assume that it is responsible for designing CTDL itself or independently developing Credential Registry import architecture for these classes.

      However, CTDL xTRA-specific extraction mappings, property selections, transformations, validation rules, and CSV generation workflows will need to be implemented or refined for each class. Credential Engine’s engineering team will lead publishing system integration and Registry infrastructure work, with the consultant focusing primarily on the AI/ML extraction, transformation, evaluation, and workflow capabilities.

45. The RFP emphasizes “reproducible” workflows. How do you define a “successful” or “identical” extraction when the source web content, such as a university course catalogue, is dynamic and changes slightly each time it is fetched?
    • Credential Engine does not interpret reproducibility to mean that extraction results must remain literally identical when the underlying source information has changed. We expect reproducibility to include the ability to understand and recreate how an extraction result was produced based on the source content available at that time, the extraction configuration and workflow, relevant model and prompt or instruction versions, validation rules, and other material processing inputs. For unchanged or materially equivalent source content, workflows should produce highly consistent structured results. When source information changes, the system should be able to identify meaningful changes and distinguish them from extraction variability wherever practical. Versioning, provenance, auditability, regression testing, and transparent workflow behavior should therefore be important parts of the proposed approach to reproducibility.
46. The RFP asks for “Intuitive extraction configuration… approaches that reduce or eliminate manual extraction configuration.” Is the expectation to build a fully automated, AI-driven self-service configurator, or a manual “point-and-click” UI tool for a power-user to train the system?
    • Credential Engine is not prescribing either of those approaches as the sole solution. The objective is to reduce unnecessary manual configuration while providing users appropriate visibility and control over extraction workflows. The RFP specifically welcomes visual configuration tools, automated identification of extraction patterns and document structures, reusable configurations, and approaches that reduce or eliminate manual configuration where appropriate. Respondents should recommend the appropriate balance of automation, reusable configuration, visual tools, and human oversight. We expect the platform to become progressively easier to configure and operate without sacrificing transparency, reproducibility, or extraction quality.
47. Are there already-scheduled partner or institution commitments, such as states or statewide systems expecting onboarding, that create deadlines within Year 1?
    •  Credential Engine is currently working with four states and is conducting landscape analyses with participating states and partners to identify sources, priorities, and publication opportunities. Participating states will be shared as those engagements are formalized.
      There are also preliminary Year 1 planning estimates that include publication of approximately 326,000 additional credential records across multiple credential types.

      The RFP does not establish respondent-facing implementation deadlines tied to individual states or institutions beyond the overall Year 1 objectives and the goal of expanded production-ready capabilities during the first six months. Any partner-specific schedules or dependencies relevant to implementation will be shared with the selected partner as the detailed scope and implementation plan are developed.

48. Is the Credential Engine “full-time software engineer” dedicated solely to this project, or split across other priorities? This affects realistic collaboration bandwidth.
    •  The RFP states that Credential Engine will assign a full-time software engineer to work directly with the selected consultant throughout the engagement. This means Credential Engine is committing full-time engineering capacity to support the work, but the RFP does not specify that the engineer will work exclusively on CTDL xTRA to the exclusion of all other Credential Engine responsibilities. The engineer will provide consistent, ongoing collaboration and will lead or co-implement platform components, workflow integration, and publishing system integration. The selected partner should propose a working model that supports continuous progress while recognizing that Credential Engine staff also have responsibilities for the broader Credential Engine technology environment.