DARPA-PA-25-07-02-Amendment-01.pdf

DARPA-PA-25-07-02 CLARA Disruption Opportunity 1

Disruption Opportunity

DARPA-PA-25-07-02

Compositional Learning-And-Reasoning for AI Complex Systems Engineering (CLARA) Amendment 1

I. Opportunity Description

The Defense Advanced Research Projects Agency (DARPA) Defense Sciences Office (DSO) is issuing a Disruption Opportunity (DO), inviting submissions of innovative basic or applied research concepts in the technical domain of high assurance artificial intelligence systems. This DO is issued under the Program Announcement for Disruptioneering, DARPA-PA-25-07. All awards will be made in the form of an Other Transaction (OT) for Prototype project. The total award value for the combined Phase 1 base (Feasibility Study) and Phase 2 option (Proof of Concept) is limited to $2,000,000. This total award value includes Government funding and performer cost share if required or proposed.

To view the DARPA Program Announcement (PA) for Disruptioneering, visit SAM.gov under solicitation number DARPA-PA-25-07:

https://sam.gov/opp/bae5fa32f4ee4cdb9a070a14309b2c66/view.

A. Introduction

CLARA is an exploratory, fundamental research program that aims to create high assurance, broadly applicable AI systems of systems. This will be accomplished by creating a scientific, theory-driven architectural foundation for the hierarchical composition of a wide variety of both Machine Learning (ML) and Automated Reasoning (AR), also known as Knowledge Representation and Reasoning, subsystems. CLARA seeks to create a foundation that is algorithmic, highly reusable, and computationally scalable. For CLARA, AI systems of systems means systems that are hierarchically composed of constituent subsystems that employ ML and AR techniques and also contain both ML and AR models whose outputs are composed to create the overall system response. Assurance here means verifiability with strong explainability to humans, based on automated logical proofs and hierarchical, vetted logic building blocks.

DARPA anticipates that successful performers in this program will combine innovations such as higher order logic, probabilistic logic, logical expressivity, hierarchically structured knowledge representation, and interoperable integration of AR and ML. The range of practically important ML and AR techniques and associated model families (termed “kinds” here and fully listed out in section I.H.) that will be explored within this program as constituents for hierarchical composition includes, but is not limited to, Neural Networks (NN), Bayesian ML, Reinforcement Learning (RL), Generalized Additive Models (GAM), Logic Programs (LP), Classical logic, and Answer Set Programs (ASP). Here, LP, Classical, and ASP might also be extended by constraints, a.k.a. constraint programming.

Specifically excluded from CLARA are families that do not have a viable path to computational scalability of model inferencing and (ML) training. An example of such a family would be unrestricted higher-order Classical logic. Also excluded is research that primarily results in evolutionary improvements to the existing state of practice.

B. Background https://sam.gov/opp/bae5fa32f4ee4cdb9a070a14309b2c66/view

DARPA-PA-25-07-02 CLARA Disruption Opportunity 2

While there has been extensive progress in AI systems of systems over the decades, widespread adoption has been impeded by the need for high assurance that has in turn been impeded by the stark trade-off today between ML and AR with respect to assurance and applicability. ML has broad applicability, i.e., low marginal cost per new functional task. A person not trained in AI or programming can effectively utilize an ML-based Large Language Model (LLM) system like ChatGPT and, using natural language, ask it to take on a new task. However, ML overall has weak assurance, particularly weak explainability. In contrast, AR has verifiability, with some kinds having strong explainability and, thus, high assurance. However, AR has relatively narrow applicability. A fundamental cause of this weakness in applicability is AR’s struggle with tractability (i.e., computational scalability) when expressiveness is high enough to encompass the forms of knowledge and the patterns of inferencing that ML can do. Expressiveness here means flexibility in the form of knowledge statements and in the patterns of reasoning with that knowledge.

A notable example of AR with high assurance is Logic Programs, which dominate enterprise IT areas such as data management, ontologies, knowledge graphs, and rule-based systems. This cluster of areas and associated systems has strong composability, including strong interoperability via automated translations and Web standards, underpinned by a theory-driven foundation. This foundation includes mathematical results and associated analytic guarantees about generalizations/specializations, semantics, equivalences, proof theory, and computational complexity. CLARA seeks to emulate the success of DARPA’s DAML1 program (2000-2005), which pioneered standards and design for the semantic web through a similar theory-driven foundation, but in a new arena – AR-based ML.

AR-based ML means that ML is achieved via AR where the ML is put onto a logical footing, including both ML inferencing and training. One way to view ML as being AR-based is that induction (in the sense of inductive reasoning with probabilistic generalization, rather than in the sense of mathematical induction/deduction) is viewed as deduction in a high-expressiveness form of logic/AR.

The dual requirements of high assurance and broad applicability for AR-based ML pose two key technical challenges for the program. The first, Applicability, is how to extend high assurance (of the type available for Logic Programs) widely to various ML/AR kinds and across a composition of heterogeneous subsystems that are based on those kinds. The second, Tractability, is how to break the tension between expressiveness and tractability in the relevant kinds of high assurance AR.

There are several examples of systems that give preliminary hope that AR-based ML systems can be built, but they have significant limitations and have yet to fully overcome the Applicability and Tractability challenges. The DeepProbLog2 system and subsequent follow-up DeepStochLog3 system show how to do ML inferencing based on Bayesian probabilistic Logic Programs (“Bayesian-LP”) and how to do limited integration of that with Neural Networks ML.

1 The DARPA Agent Markup Language Homepage. DAML.org. (2001, January 25). https://www.daml.org/ 2 Manhaeve, R., et al. (2021). Neural probabilistic logic programming in DeepProbLog. Artificial Intelligence, 298, 103504.

3 Winters, T., et al. (2022). DeepStochLog: Neural Stochastic Logic Programming. Proc. AAAI conference.

https://www.daml.org/

DARPA-PA-25-07-02 CLARA Disruption Opportunity 3

However, they lack worst-case polynomial-time computational tractability, sophisticated criteria for ML training (i.e., beyond optimizing a directly specified numerical loss function), and a number of high-expressiveness AR features (e.g., logical functions, HiLog, defeasible argumentation, and restraint; also reification, web-style annotation leveraging rule identifiers, external queries, and modules) that are desirable for composing with various AR systems and for overall AR-based ML.

Other existing approaches to AR-based ML include Inductive Logic Programming4, Logical Tensor Networks5, Real Valued Logic for Logical Neural Networks6, 7, and more, but these are importantly limited in expressiveness and/or tractability and/or practical usefulness and broad applicability. Several promising techniques that help address the Applicability challenge include concept bottlenecks8, 9 (e.g., for Neural Networks) and computing logic programs as tensor operations.10, 11, 12 There is also substantial progress in the Tractability challenge through advances such as bounded rationality techniques, including restraint13, 14, together15, 16 with HiLog17 that make tractable higher-order logic. Several open-source software stacks have also recently been released for systems that start to address these two challenges, including the DeepProbLog system for Neural Networks with Bayesian-LP18 on top of ProbLog219 for Bayesian LP, the cplint/PITA system20 for Bayesian and fuzzy-logic LP, and ErgoAI21 on top of XSB22 for higher-order defeasible LP with restraint. With the recent research advances, it now appears to

4 Cropper, A., Dumančić, S., Evans, R. et al. Inductive logic programming at 30. Mach Learn 111, 147–172 (2022).

https://doi.org/10.1007/s10994-021-06089-1 5 Serafini, L., et al. (2021). Chapter 17. Logic Tensor Networks: Theory and Applications. In Frontiers in artificial intelligence and applications. https://doi.org/10.3233/faia210498 6 Fagin, R., et al. (2024). Foundations of reasoning with uncertainty via real-valued logics. Proceedings of the National Academy of Sciences, 121(21). https://doi.org/10.1073/pnas.2309905121 7 Riegel, R., et al. (2020). Logical Neural Networks. arXiv.org. https://arxiv.org/abs/2006.13155 8 Koh, P.W., et al. (2020). Concept Bottleneck Models. Proceedings of the 37th International Conference on Machine Learning, in Proceedings of Machine Learning Research 119:5338-5348 Available from https://proceedings.mlr.press/v119/koh20a.html 9 Hu, L., et al. (2024). Semi-supervised concept bottleneck models. arXiv.org. https://arxiv.org/abs/2406.18992 10 Inoue, K. (2024). Linear Algebraic Approaches to Logic Programming [Conference Presentation]. ICLP.

11 Inoue, K. (2024). Algebraic connection between logic programming and Machine Learning [Extended Abstract]. FLOPS. In Lecture notes in computer science (pp. 3–9). https://doi.org/10.1007/978-981-97-2300-3_1 12 Domingos, P. (2025, October 14). Tensor Logic: the language of AI. arXiv.org. https://arxiv.org/abs/2510.12269 13 Grosof, B., & Swift, T. (2013). Radial restraint: A semantically clean approach to bounded rationality for logic programs.

Proceedings of the AAAI Conference on Artificial Intelligence, 27(1), 379-386.

14 Andersen, C., et al. (Eds.). (2013). Advanced Knowledge Base Debugging for Rulelog (Vol. 1004). CEUR-WS. https://ceur-ws.org/Vol-1004/paper8.pdf -- Notably, See Section 4 of the paper.

15 Grosof, B., et al., Ergo: A Quest for Declarativity in Logic Programming, in: Warren, David S., et al. (eds), Prolog: The Next 50 Years. Lecture Notes in Computer Science(), vol 13900. Springer, Cham. https://doi.org/10.1007/978-3-031-35254-6_18 16 Swift, T., Kifer, M. (2025). Multi-paradigm Logic Programming in the ErgoAI System. In: Dodaro, C., Gupta, G., Martinez, M.V.

(eds) Logic Programming and Nonmonotonic Reasoning. LPNMR 2024. Lecture Notes in Computer Science(), vol 15245.

Springer, Cham. https://doi.org/10.1007/978-3-031-74209-5_10 17 Chen, W., Kifer, M., & Warren, D. S. (1993). HiLog: A foundation for higher-order logic programming. The Journal of Logic Programming, 15(3), 187–230. doi:10.1016/0743-1066(93)90039-J 18 Manhaeve, R., et al. (2024). DeepProbLog [Software]. https://github.com/ML-KULeuven/deepproblog 19 De Raedt, L., et al. (2025). ProbLog2 [Software]. https://github.com/ML-KULeuven/problog 20 Riguzzi, F., & Azzolini, D. (2025). cplint (4.5) [Software]. https://friguzzi.github.io/cplint/_build/latex/cplint.pdf 21 Kifer, M. et al. ErgoAI software, manuals & tutorials, https://github.com/ErgoAI 22 Swift, T., et al. (2022) XSB software & manuals, https://xsb.sourceforget.net https://doi.org/10.1007/s10994-021-06089-1 https://doi.org/10.3233/faia210498 https://doi.org/10.1073/pnas.2309905121 https://arxiv.org/abs/2006.13155 https://proceedings.mlr.press/v119/koh20a.html https://arxiv.org/abs/2406.18992 https://doi.org/10.1007/978-981-97-2300-3_1 https://arxiv.org/abs/2510.12269 https://ceur-ws.org/Vol-1004/paper8.pdf https://ceur-ws.org/Vol-1004/paper8.pdf https://doi.org/10.1007/978-3-031-35254-6_18 https://doi.org/10.1007/978-3-031-74209-5_10 https://github.com/ML-KULeuven/deepproblog https://github.com/ML-KULeuven/problog https://friguzzi.github.io/cplint/_build/latex/cplint.pdf https://github.com/ErgoAI https://xsb.sourceforget.net/

DARPA-PA-25-07-02 CLARA Disruption Opportunity 4 be possible to create an AR-based ML approach that puts ML inferencing and training on a tractable AR footing, achieving the CLARA program’s goals.

C. Technical Areas

CLARA is composed of two Technical Areas (TAs). Each proposal should address only one Technical Area. An institution/organization (e.g., a single university or a single organization ) may not be selected for both TA1 and TA2. A program-wide set of activities will be developed and supported by an Independent Verification and Validation (IV&V) team, who will also perform reviews and evaluations of many of the performers’ deliverables. IV&V will be separately competed and is not part of this solicitation.

TA1 is the primary area of work. Each TA1 performer will create one or more new approaches for high assurance ML/AR, which are AR-based ML based. Each approach will modify and tightly compose a few kinds of ML and AR selected from those listed in section I.H. During this program, TA1 performers will:

Develop a theory for high assurance ML/AR approaches, including algorithms;

expressive and syntactic generalizations/extensions and specializations/restrictions, with corresponding characterizations and guarantees for verifiability (including strong explainability and the corresponding logical explainability properties discussed in section I.E.); computational tractability/scalability; and translations among ML and AR kinds

Create initial open-source software implementing algorithms for experiments about and demonstrations of their approach, including AR-based ML inferencing and training

Exhibit the enhancements of their approach per the phase metrics listed in Figure 1 Work with the IV&V team to identify specific inter-performer-team approach compositions that would be most fruitful to explore in Hackathons, discussed later in this section

Tackle AR-based-ML training in a computationally feasible manner for large problem sizes and demonstrate scalability of this training

Ensure AR-based-ML models can be rapidly adapted to previously unseen data through means such as, but not limited to, minimal additional training data or human/manual editing/updating of model knowledge (e.g., of model rules and facts)

TA2 will develop a software composition library that will support inter-approach compositions, performing low-lift integration of the IV&V team validated TA1 tools and other software into a central hub. TA2 will have significantly fewer performers than TA1, with performers working closely with the IV&V team. During this program, TA2 performers will:

Integrate the IV&V team validated TA1 performer approaches into a common software library of tools. This TA2 created library should implement common structures between differing performer approaches, such as common terminology, theoretical/conceptual elements, standardized data formats, software functionalities such as interfaces, and end-to-end explanations, where each step of explanation would be provided by the relevant TA1 componentry. The low-lift integration of TA1 tools by TA2 may include refactoring the tools to integrate into the common library but should not include new development of TA1 theory or algorithms nor of other TA1 outputs/products.

DARPA-PA-25-07-02 CLARA Disruption Opportunity 5

Work alongside the IV&V team to enable program wide activities. The IV&V team will specify composition patterns between distinct TA1 approaches that TA2 performers will need to ensure are prepared in their library prior to the Hackathons, e.g., through orchestrations such as common data formats and interface protocols. The IV&V team will specify the composition patterns to TA2 performers at least 45 days prior to the Hackathon start date.

Program Wide Activities

All TA1 and TA2 performer teams are expected to participate in three kinds of program-wide activities: Phase Kickoff Meetings, Workshops and Hackathons. Participation is expected to only require a fraction of the overall labor effort of each performer team.

Phase Kickoff Meetings will be held at the beginning of each phase and are expected to discuss overall programmatic foci and performers’ plans for the upcoming phase.

Workshops will focus on intense, critically argumentative discussion of the various TA1 approaches’ advantages and disadvantages, the best way to compose ML and AR kinds, and identifying common structure (including terminology and interfaces) for the TA2 library.

Hackathons are wide-scope integration exercise scenarios developed by the IV&V team in consultation with the TA1 and TA2 performers. In a Hackathon, each TA1 performer team solves the same one or more scenarios by utilizing potentially all of the TA2 library. Scenarios will be scoped to motivate each TA1 performer team to use a broad set of TA2 modules, well beyond what any one TA1 performer team itself has developed. During the Hackathons, the TA2 performers will provide software support for their library to the IV&V team and to all the TA1 performers. A partial kill web integrating limited components of target recognition, tracking, weapons selection, triaging decision support, etc., is an example of a possible Hackathon scenario that begins to emulate the composition required for real-world national security challenges.

Hackathon attendance is included in the milestone schedule. In addition, each Hackathon will have a milestone and corresponding payment associated with it, which only the top performing TA1 Hackathon team may qualify for. This milestone payment will be significantly smaller than all other milestone payments and is intended to incentivize Hackathon performance. Hackathon incentive payments will count towards the total $2,000,000 funding cap allowed in the program, meaning that non-Hackathon milestone costs should total no more than $1,940,000.

Further information on Milestones can be found in section I.F.

D. Program Description / Scope

The primary focus of the CLARA program is the development of a scientific, theoretical foundation for engineering AI systems of systems by creating high assurance, broadly applicable, AI compositions. Performer approaches are expected to tightly couple ML and AR building blocks on an AR scaffolding and provide the capability to train (in the ML sense of training) across the composition, creating a logic-based shared knowledge structure and meaning (often referred to as semantics), while strengthening system-of-systems composability and reusability. Strong explainability with logic-based shared meaning (based on knowledge

DARPA-PA-25-07-02 CLARA Disruption Opportunity 6 and well-studied principles for what conclusions are sanctioned versus not) is anticipated to enable non-AI-experts, such as system engineers, end users, and adoption stakeholders, to perform line level editing/debugging of the knowledge in AI systems, such as in the Enterprise Data Management Council’s Financial Industry Business Ontology (FIBO) Rules RegW application pilot23 system. Such strongly transparent agility for updating by humans, together with the strengths of ML, is anticipated to enable more rapid adaptability of AI systems and would potentially transform AI DevOps.

TA1 performer approaches will focus on developing this tight coupling of AR and ML systems with strong explainability properties, while considering potential implications for AI DevOps. At a minimum, TA1 proposals must include:

A proposed AR-ML composition approach, with substantiation of the proposed composition based on theoretical analysis. The analysis must include a discussion of why the proposed composition approach would be capable of providing the desired logical explainability properties (outlined in section I.E), what applicable techniques are expected to be utilized to meet the tractability requirements, and analysis of other similar ML and/or AR kinds that the composition could potentially expand into

A description of the proposed approach’s research and development efforts and a description of what will be developed and demonstrated during the program

A proposed unclassified application task domain (set of problems) for the approach, with explicit state-of-the-art (SOA) performance benchmarks to compare against and corresponding train/test corpuses. The proposed domain should be relevant to the DARPA mission, with several potential options laid out at the end of this section. At least one SOA benchmark should have an associated, identified pair or larger set of previously existing ML and AR models. The SOA performance should have an associated sample complexity. See section I.E for further details on SOA comparison points and sample complexity

A comparison of the proposed approach’s anticipated enhancements for aspects of AI DevOps, such as the logical explainability properties over the relevant processes today

An identification of risks associated with the proposed approach (Risk mitigation strategies must be adequately described with clear statements of how the proposed research plan addresses the dominant risks early in the program)

Substantiation of the proposed software or key software package(s) that will be used as implementation(s) of the approach’s relevant techniques. This description should include a clear analysis of the software-to-software connections that will be made if using different software for the proposed AR and the proposed ML

Clear delineation of how and why the approach will meet the program’s goals and metrics

TA2 proposals will focus on demonstrating prior expertise in relevant software integration (including in development of common libraries, APIs, and UIs), detailing expertise in the

23 Grosof, B. et al. (2015) Automated Decision Support for Financial Regulatory/Policy Compliance, using Textual Rulelog, 9th Intl. Web Rule Symposium (RuleML-2015) industry track demonstration and paper.

DARPA-PA-25-07-02 CLARA Disruption Opportunity 7 common areas of AR and ML, and delineating their proposed high-level technical approach and on mechanisms that the proposer will utilize to encourage collaboration with TA1 performers.

At a minimum, TA2 proposals must include:

A proposed integration approach. The approach must account for the necessary modularity between and among TA1 performer solutions. It must also detail plans to enable scalability of the library to accommodate additional TA1 composition patterns developed throughout the program. In addition, it must identify expected methods to enable interoperability between diverse software that TA1 performers may use

Identification of the proposed software or key software package(s) that will be used to implement the library. This should include the programming language or tools into which the performer anticipates potentially refactoring TA1 approaches

Proposed mechanisms to encourage collaboration between the proposer and TA1 performers, such as encouraging adoption of the proposer’s software composition library through regular meetings or bug-tracking systems

Past examples of the proposer’s software integration expertise. In particular, cases where the software to be integrated was developed concurrently with the software integration process

Past examples of the proposer’s experience with common kinds of ML and AR, in particular, the development, refactoring, or implementation of algorithms associated with the discussed kinds

Past examples of the proposer’s experience in developing demonstration events, in particular, cases where their developed software was demonstrated to a military and/or other defense audience; cases where the development of the demonstration involved other parties’ work (e.g. sub-contractors); and/or cases focused on oversight, interaction, or explainability of AI models.

Potential Application Task Domains

Some potential application problem domains with corresponding examples of composed tasks in which proposers might demonstrate their approach include:

Course of Action (COA) genesis, planning, and/or evaluation: How can one create a COA that obeys constraints such as supply limitations. Can generated COAs be provided with logical explanations and decomposed into sub-decisions or COAs for smaller-size units?

o Composed Task Example: Threat assessment prediction (via ML) and associated target decisions (via AR). An unclassified proxy for a COA system might be non-military games

Multi-condition medical guidance: How to treat patients who have multiple interacting conditions, in contrast to SOA medical treatment guidance that is often developed based on the assumption that there is a single patient condition o Composed Task Example: Medical treatment decisions, based on ML (notably, predictions of treatment actions’ effects) and AR. (The ML might also include diagnosis.)

Supply chain and logistics: For instance, predictive maintenance and/or digital twins that support analysis and optimization

DARPA-PA-25-07-02 CLARA Disruption Opportunity 8 o Composed Task Example: Prediction of maintenance requirements (via ML) and supply chain schedules or flows (via AR)

E. Structure

Submissions in response to this DO must be unclassified and must address two independent and sequential project phases: a Phase 1 base and a Phase 2 option. The periods of performance for these phases are 15 months for Phase 1 and 9 months for Phase 2. Combined Phase 1 and Phase 2 for this DO must not exceed 24 months. The total award value for the combined Phase 1 and Phase 2 is limited to $2,000,000. This total award value includes Government funding and performer cost share, if required or if proposed. Up to $100,000 may be shifted between phases to match performer’s anticipated distribution of their effort. The Phase 1 (base) award value is limited to $1,350,000. The Phase 2 (option) award value is limited to $850,000.

Phase 1 (15 months) will focus on the development of initial theory, tools, experiments, and validation versus SOA for the performers’ approaches to high assurance ML/AR composition and set the stage for composition across/among those approaches.

Phase 2 (9 months) will build upon Phase 1 efforts by extending compositional approaches to additional kinds of ML and potentially additional kinds of AR as well, while more thoroughly demonstrating the utility of the approaches and compositions of distinct performer’s approaches. In addition to the metrics for Phase 1, Phase 2 adds AR-based-ML training with Sample Complexity considerations.

Metrics

The metrics which will be used to evaluate performer progress are outlined in figure 1 below.

TA Metric for performer approach Phase 1 Phase 2 Verifiability without loss of performance

• Includes logical explainability Fully Verifiable;

Error rate ≤ SOA

Fully Verifiable;

Error rate ≤ SOA

Multiplicity of AI Kinds in Composition

• Intra-performer: # of kinds tightly composed

• Inter-performer: wider composition patterns

Intra:

≥1 ML & ≥1 AR ;

Inter: hackathons

Intra:

≥2 ML & ≥1 AR ;

Inter: hackathons

Computational Time complexity is Polynomial For Inferencing For Inferencing & Training

Composed Task Reliability of ML+AR system CLARA built, versus traditionally built (SOA), as measured by Area Under Receiver Operator Curve (AUROC) or similar

> SOA > SOA

TA

Sample Complexity in training for new task Size of training data for CLARA built, versus traditionally built (SOA) to adapt to new task

NA < SOA

TA

Wide Integration Competence in Composition

• Integrates functionally all TA1 tools

Patterns, including hackathons

Patterns, including hackathons

DARPA-PA-25-07-02 CLARA Disruption Opportunity 9

Figure 1: Program Metrics

Further details on the metrics are provided below:

Verifiability without loss of performance: Verifiability will be based upon automatic proofs of soundness, completeness, and approximation. The SOA benchmark should be proposed by the proposer, as outlined in section I.D. Logical Explainability is discussed later in this section.

Multiplicity of AI Kinds in Composition: Inter-performer is a pass/fail criterion of whether the given TA1 performer participated in the relevant phase’s Hackathon and attempted to utilize other TA1 performers’ approaches within the Hackathon.

Computational Time complexity is Polynomial: The computational time complexity of model inferencing must be at worst polynomial or able to practically scale to large input sizes, e.g., to millions of clauses as in Satisfiability (SAT) solving. Performers must demonstrate scalability through theory work and/or empirically (i.e., via experiments), preferably through both.

Composed Task Reliability of ML+AR system: This will be a head-to-head comparison between a state of the art ML-AR composition and a CLARA built version of the same composition. Several examples of composition tasks are laid out in the Potential Application Task Domains subsection under section I.D. The SOA to be compared against is proposed by the proposer, as outlined in section I.D, with the comparison done using a common performance metric (such as AUROC). The performer will ensure (verified by the IV&V team) that the test data set includes edge cases that are anticipated to be problematic for AI analysis, including classic cases and purposefully designed edge-cases and challenge cases for assessments to red-team systems both within and beyond typical performance parameters where AI systems tend to hallucinate or fail.

Sample Complexity in training for new task: It is anticipated that novel methods of updating model knowledge and/or reasoning will be developed during the CLARA program that will not follow the standard ML training-with-additional-data paradigm; for instance, directly updating models through interactions with interpretable, higher-level abstractions such as rules or concept bottlenecks.

Wide Integration Competence in Composition: The TA2 libraries will include all performer tools, support structures, and IV&V-identified composition patterns as outlined in section I.C.

Proposers should note that meeting the Phase 1 metrics does not guarantee a Phase 2 award.

Likewise, if a performer fails to meet the Phase 1 metrics but has a highly innovative and potentially disruptive approach, DARPA may decide to continue those efforts into Phase 2, subject to the availability of funds.

Common Comparison Point

The IV&V team will be responsible for developing a simple ML/AR baseline system that could be easily tuned to each performer’s task domain to provide a common reference point across TA1 performer teams. TA1 performer’s individual SOA comparison points would be considered the maximum performance of the IV&V system and the performer’s identified SOA.

Logical Explainability Properties

DARPA-PA-25-07-02 CLARA Disruption Opportunity 10

TA1 performer approaches are expected to include Logical Explainability Properties intended to enable significant AI DevOps advantages over current ML models. All proofs, as in the Verifiability without loss in performance metric, are expected to include the following logical explainability properties: hierarchical, fine-grained, and natural deduction style, with low (≤ 10) unfolding expansion between hierarchical levels (e.g., unfolding the justification of a Logic Program rule’s head literal into a set of its body literals).

Such properties create the strong explainability necessary for achieving the program’s technical aims and are anticipated to enable the editing of model knowledge and reasoning discussed previously. Development of additional explainability and editability mechanisms for a proposer’s approach are welcome but not the primary goal of the CLARA program.

F. Schedule/Milestones

Proposers must address the following fixed payable milestones in their proposals. Proposers must complete the “Schedule of Milestones and Payments” tab of the appropriate Streamlined Cost Buildup Workbook (TA1 or TA2) provided with this DO to fulfill the requirements under Volume 2, Price Volume. If selected for award negotiation, the fixed payable milestones provided will be directly incorporated into Attachment 3 of the OT agreement (“Schedule of Milestones and Payments”). Proposers must use the Task Description Document template provided with the Program Announcement DARPA-PA-25-07, which will be Attachment 1 of the OT agreement.

Phase 1 fixed milestones for TA1 performers on this program must include, at a minimum, the following:

Month 1: Participation in Phase 1 project kick-off meeting. All supporting positions identified in the proposal are assigned to personnel, and names are provided to the Government.

Month 3: Progress report identifying data sources to be used for metric benchmarking, identifying and justifying the SOA baselines for those metrics, and describing the modifications to the composed AR-ML approach relative to those initially proposed. All proposed personnel must be working on the project at the planned level of effort, and Associate Contractor Agreements must be in place.

Month 6: Demonstration of initial composed AR-ML capability. Progress report detailing performer experience relative to Phase 1 metrics, insights, and obstacles encountered.

Month 9: Demonstration of composed AR-ML capability. Progress report detailing performer experience relative to metric targets and plans to achieve (end of) Phase 1 metrics. Provision of any relevant theory work plus software, documentation and training materials to support IV&V team's initial verification and validation and Phase 1 Hackathon preparation.

Month 12: Demonstration of first place performance in Phase 1 Hackathon.

Month 12: Demonstration of composed AR-ML capability. Progress report detailing performer experience of Phase 1 hackathon, inter-performer approach compositions, and generalizations of approaches. Provision of any relevant theory work plus software, DARPA-PA-25-07-02 CLARA Disruption Opportunity 11 documentation, and training materials. Participated in Phase 1 Hackathon.

Month 15: Demonstration of composed AR-ML capability on performer's selected use-case. Phase 1 final report detailing performer experience relative to Phase 1 metrics, insights, and obstacles encountered. Provision of any relevant theory work plus software, documentation, and training materials.

Phase 2 fixed milestones for TA1 performers on this program must include, at a minimum, the following:

Month 18: Demonstration of composed AR-ML capability. Progress report detailing plans and progress for incorporating additional kinds of AI into performer approaches.

Provision of any relevant theory work plus software, documentation, and training materials to support IV&V team's verification and validation and Phase 2 Hackathon preparation.

Month 21: Demonstration of composed AR-ML capability. Progress report detailing performer experience relative to metric targets and plans to achieve (end of) Phase 2 metrics. Provision of any relevant theory work plus software, documentation, and training materials.

Month 22: Demonstration of first place performance in Phase 2 Hackathon.

Month 24: Demonstration of composed AR-ML capability on performer's selected use-case. Phase 2 final report detailing performer experience relative to Phase 2 metrics, insights, and obstacles encountered. Provision of any relevant theory work plus software, documentation, and training materials. Participated in Phase 2 Hackathon.

Phase 1 fixed milestones for TA2 performers on this program must include, at a minimum, the following:

Month 1: Participation in Phase 1 project kick-off meeting. All supporting positions identified in the proposal are assigned to personnel, and names are provided to the Government.

Month 3: Progress report including UI wire-frame diagrams, proposed standard data formats, implementations of mechanisms to encourage communications with other performer teams, and any modifications to their original software library proposal. All proposed personnel must be working on the project at the planned level of effort, and Associate Contractor Agreements must be in place.

Month 6: Demonstration of initial software library interface and other software library common structural elements. Progress report describing the design of the software library and detailing common structural elements included or planned for the software library.

Month 9: Demonstration of software library. Progress report describing the modified design of the software library, detailing software incorporated into the library, comparisons of the software versus the original implementations, plans for Phase 1 Hackathon preparation, and commonality analysis of features across software library

DARPA-PA-25-07-02 CLARA Disruption Opportunity 12 constituents. Provision of software, documentation, and training materials.

Month 12: Demonstration of software library. Progress report describing the modified design of the software library, detailing initial Phase 1 Hackathon information, software incorporated into the library and comparisons versus the original implementations, and analysis of common inter-performer-team approach compositions. Provision of software, documentation, and training materials. Provided real-time support during Phase 1 Hackathon to teams using software library.

Month 15: Demonstration of software library. Phase 1 final report detailing performer experience relative to Phase 1 metrics, insights, and obstacles encountered. Provision of software, documentation, and training materials. Submit DARPA's Public Release of Software, Artifacts, and Code process documents for software library.

Phase 2 fixed milestones for TA2 performers on this program must include, at a minimum, the following:

Month 18: Demonstration of software library. Progress report describing the modified design of the software library, detailing software incorporated into the library, comparisons of the software versus the original implementations, and plans for Phase 2 Hackathon preparation.

Month 21: Demonstration of software library. Progress report detailing initial Phase 2 Hackathon information, software incorporated into the library and comparisons versus the original implementations, analysis of common inter-performer-team approach compositions, and commonality analysis of features across software library constituents. Provision of software, documentation, and training materials.

Month 24: Demonstration of software library. Phase 2 final report detailing performer experience relative to Phase 2 metrics, insights, and obstacles encountered. Provision of software, documentation, and training materials. Provided real-time support during Phase 2 Hackathon to teams using software library. Submit DARPA's Public Release of Software, Artifacts, and Code process documents for software library.

Figure 2 describes and depicts the overall schedule for CLARA, including major program activities and some anticipated interplays between TAs and IV&V. For planning and budgetary purposes, proposers should assume a program start date of June 22, 2026. Schedules will be synchronized across performers, as required, and monitored/revised as necessary throughout the program’s period of performance.

DARPA-PA-25-07-02 CLARA Disruption Opportunity 13

Figure 2: Program Schedule

All proposals must include the following meetings and travel in the proposed schedule and costs:

To continue integration and development across the program, foster collaboration between teams, and disseminate program developments, regular program wide events will be held approximately every 3 months, with scheduling depicted in the Program Schedule figure. They will be held in locations split between the east and west coasts of the United States. For budgeting purposes, plan for eight two-day meetings over the course of 24 months: four meetings in the Washington, D.C., area, including the Phase 1 program kickoff meeting, and four meetings in the San Francisco, California, area.

Additionally, a single week-long pair of back-to-back events should be anticipated in the Washington, D.C. area at the phase transition. Proposals should plan for two essential-personnel team members to participate in-person at each program-wide event. Hybrid support options will be available for the program-wide events to allow participation from other personnel. Phase Assessments will be virtual.

G. Deliverables

Performers will be expected to provide, at a minimum, the following deliverables:

Comprehensive quarterly technical reports are due within ten days of the end of the given quarter, describing progress made on the specific milestones as required in the SOW.

A phase completion report submitted within 30 calendar days of the end of each phase, summarizing the research done.

Other negotiated deliverables specific to the objectives of the individual efforts. These may include reports; experimental protocols; publications; data management plan; intermediate and final versions of software libraries, code, and APIs, including documentation and user manuals; and/or a comprehensive assemblage of design documents, models, modeling data and results, and model validation data.

H. Other Program Objectives and Considerations

Collaboration

Throughout the course of the program, it is likely to be necessary for performers to share

DARPA-PA-25-07-02 CLARA Disruption Opportunity 14 relevant information regarding their research and development to support the larger program goals. DARPA expects all program performers to work collaboratively with one another to realize the program objectives outlined herein. To facilitate collaboration, all performer Other Transactions will include an Associate Contractor Agreement (ACA) clause for portions of the Other Transactions requiring joint participation between each TA1 team and the TA2 team(s) in the accomplishment of the program requirements. TA1 teams will not be obligated to have ACAs with each other, ACAs will only be required between TA1 and TA2 teams. This provision will become a material requirement for any Other Transactions awarded as a result of this solicitation.

The ACA clause will include the basis for sharing information, data, technical knowledge, expertise, and/or resources essential to the integration of TA1 components. This clause will ensure appropriate coordination and integration of work by program contractors, ensure complete compatibility between data, tools and services, and prevent unnecessary duplication of efforts and maximize commonality. Without exception, all ACAs must be in place within three months of the Other Transactions award date. See the attached Sample Associate Contractor Agreement Clause.

Intellectual Property

Software developed over the course of the program is expected to be open sourced with a commercialization-friendly license, preferably Apache 2.0. Such software developed over the program includes (but is not limited to) the reusable (domain-independent) tools that implement the approaches developed by individual TA1 teams and the TA2 composition library.

Potential Automated Reasoning Kinds

Performers should select at least one of the following kinds (presented without ranking below) of AR as a point of departure (for modifying, including to expressively extend and/or restrict) for their high-assurance scientific approach. These kinds are hierarchical; performers may select a broader kind (e.g., Logic Programs), rather than a narrower kind (e.g., Bayesian-LP).

Logic Programs (in the declarative sense; note this is also known as “Rules”) o e.g., Bayesian-LP (also known as Probabilistic-LP)

Classical Logic o e.g., Propositional Classical

Answer Set Programs

These kinds of AR might also be extended by Constraints a.k.a. constraint programming. These kinds of AR might also expressively include, but not be limited to, an intersection with fuzzy (as in fuzzy logic) or an extension that covers fuzzy (as in fuzzy logic; note that Triangular Norms, and Real Valued Logics by Fagin et al are deemed here to be fuzzy).

Specifically excluded are AR families that do not have a viable path to computational scalability of AR including AR-based ML (model) inferencing and (ML) training. An example of such a family would be unrestricted higher-order Classical logic.

DARPA-PA-25-07-02 CLARA Disruption Opportunity 15

If performers do not propose one of the identified kinds of AR, they must provide compelling evidence for logical high assurance, including full verifiability, including proof theory and model theory (also known as semantics); strong explainability to humans, including logical properties providing low cognitive burden for human understanding, such as natural deduction style proofs with small unfolding expansions (note small here means practically controllable to be under 10); and computational scalability (such as worst-case polynomial time complexity).

Potential Machine Learning Kinds

Performers should select at least one of the following kinds (presented without ranking below) of ML for their high-assurance scientific approach. These kinds are hierarchical; performers may select a broader kind (e.g., Bayesian or Neural Network), rather than a narrower kind (e.g., Hidden Markov Model). Note that many of these kinds listed below are described, as they frequently are in the scientific literature, in terms of the target representational form of the machine-learned model.

Bayesian:

o Bayes Nets (a.k.a., Bayesian Networks) o Bayesian LP-based Machine Learning o Markov Logic Network o Decision Trees o Statistical Relational Learning o Expectation Maximization o Hidden Markov Model

Inductive Logic Programs / Meta-Interpretive Learning

Neural Networks (NN):

o Recurrent NNs o Convolutional NNs o Multi-layer Perceptron NNs o Transformer-based NNs o Generative Adversarial Networks o Neural Additive Models

Reinforcement Learning

“Arithmetic”:

o Regression (logistic, lasso, K- nearest neighbor, etc.)

o Support Vector Machines o Generalized Additive Models

These kinds of ML might also be extended by ensemble’ing techniques, such as boosting, e.g., Random Forests extend Decision Trees by ensemble’ing.

Performers may propose other kinds of ML for their scientific approach. If they wish to do so, they must provide compelling evidence for the other ML kind’s practical importance, broad applicability, and computational scalability. It will also be helpful for the performer to provide a

DARPA-PA-25-07-02 CLARA Disruption Opportunity 16 brief high-level description of the other ML kind’s technical similarities, if any, to one or more of the above-listed ML kinds.

II. Award Information

Selected proposals that are successfully negotiated will result in the award of an OT for Prototype project. See Section 4 of DARPA-PA-25-07 for information on awards that may result from proposals submitted in response to this announcement.

Proposers must review the model OT for Prototype agreement provided as an attachment to DARPA-PA-25-07 prior to submitting a proposal. DARPA has provided the model OT to expedite the negotiation and award process and ensure DARPA achieves the goal of Disruptioneering, which is to enable DARPA to initiate a new investment in less than 120 calendar days from idea inception. The model OT is representative of the terms and conditions that DARPA intends to include in all DO awards. The task description document, schedule of milestones and payments, and data rights assertions requested under Volumes 1, 2, and 3 will be included as attachments to the OT agreement upon negotiation and award.

Proposers may suggest edits to the model OT for consideration by DARPA and provide a copy of the model OT with track changes as part of their proposal package. DARPA may or may not accept suggested edits. The Government reserves the right to remove a proposal from award consideration should the parties fail to reach an agreement on OT award terms and conditions.

If edits to the model OT are not provided as part of the proposal package, DARPA assumes that the proposer has reviewed and accepted the award terms and conditions to which they may have to adhere and the model OT agreement provided as an attachment, indicating agreement (in principle) with the listed terms and conditions applicable to the specific award instrument.

DARPA’s goal for this DO is to achieve an award within 120 calendar days from the posting date (February 10, 2026) of this announcement. To ensure that DARPA reserves the right to cease negotiations when an award is not executed by both parties (DARPA and the selected organization) on or before June 16, 2026.

III. Eligibility

Due to their specialized roles and longstanding regulatory relationships with the Government, Federally Funded Research and Development Centers (FFRDCs) and Government Entities to include National Laboratories present potential conflicts and advantages that would compromise fair and open competition. These entities typically may only receive funding through existing awards they hold with their sponsoring agencies. If these entities are proposed as subawardees, their costs must be clearly segregable in cost proposals. If scientifically merited, DARPA may fund work proposed by these entities, provided they: (1) clearly demonstrate that the proposed work is not otherwise available from the private sector; (2) FFRDCs must provide a letter, on official letterhead from their sponsoring organization, that (a) cites the specific authority establishing their eligibility to propose to Government solicitations and compete with industry, and (b) certifies the FFRDC’s compliance with the associated FFRDC sponsor agreement’s terms and conditions. DARPA, under this solicitation, will not award separate contracts to FFRDCs as prime or subawardees but will instead leverage their existing

DARPA-PA-25-07-02 CLARA Disruption Opportunity 17 sponsors' agreements. Because of that, costs should be clearly segregable in submitted cost proposals.

While UARCs typically have statutory authority to compete with industry, internal DARPA policy views them as trusted advisors who are…