Pith. sign in

REVIEW 3 major objections 4 minor 29 references

Composable Building Blocks for Controllable and Transparent Interactive AI Systems

T0 review · 3 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Representing interactive AI systems as explicit structural building blocks exposed through a shared REST API lets both human users and LLM agents audit and control system behavior on the same terms.

desk verdict Honest, clearly written architecture proposal with a working prototype and a load-bearing validation gap; worth a short-paper review, not a full archival claim. read the letter →

arxiv 2506.02262 v1 pith:UDYOMYAW submitted 2025-06-02 cs.HC cs.AI

Sebe Vanbrabant , Gustavo Rovelo Ruiz , Davy Vanacken This is my paper
classification cs.HCcs.AI
keywords ExplainableAIInteractivesystemsTransparencyLargeLanguageModelsNeuro-symbolicModelcontrolRESTAPIBuildingblocks
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that the black-box problem of AI is not limited to individual models; it propagates to the whole interactive system, because existing explainability tools like LIME, SHAP, and the What-If tool clarify models but leave the surrounding architecture opaque. Its proposal is to describe an interactive AI system as a flow of structural building blocks—AI models plus control mechanisms drawn from the literature, such as input filters, rule guards, shutdown triggers, and ensemble splitters/aggregators—and to expose that flow as an automatically generated REST API. Accompanying visual building blocks attach model-level explanations to these structural blocks, and the same API is made available to both a human-facing interface and an LLM agent. The intended outcome, presented as a preliminary architecture with a prototype heart-disease ensemble, is that humans and automated agents share one explicit overview of system behavior, aligning human and machine interpretability.

What carries the argument

The carrying mechanism is the five-layer auditable architecture, and the named object at its center is the structural building block—a developer-chosen mapping from source-code functions (marked with decorators) to conceptual system components such as NonGoalFilter, DivineRuleGuard, or an AI model. Layer 2 automatically converts each structural building block into REST endpoints, making the system's flow machine-readable. Visual building blocks (LIME, SHAP, What-If) read those endpoints for Layer 3, Layer 4 assembles them into a user interface, and Layer 5 lets an LLM agent call the same endpoints. The API is the shared knowledge base: it is what lets the human and the automated agent work from the same representation of the system.

What would settle it

Give an LLM agent only the automatically generated REST API of the heart-disease prototype and ask it, before and after each control action (editing a NonGoalFilter rule, toggling a ShutdownTrigger, changing an ensemble weight), to predict the ensemble's output. If the agent's predictions are no better than chance, the API does not carry the semantics needed for audit; the experiment also shows what missing endpoints or data would be needed to make the claim true.

Watch

Extended reading notes

Core claim

The paper's central proposal is to treat an interactive AI system as a sequence of structural building blocks—AI models and explicitly named control mechanisms—and to expose that sequence as a shared REST API. Each block is mapped to source code by the developer through function decorators, and visual building blocks (LIME for Why, SHAP for Why-not, What-If for What-if) attach explanations to the models. The claim is that the flow and APIs of the structural building blocks constitute an explicit overview of the system, usable as a communication basis for both humans and automated agents like LLMs. Because both kinds of agents access the same API, the paper concludes that human and machine interpretability of AI models are aligned; this is the discovery the architecture is designed to enable.

Load-bearing premise

The load-bearing premise is that a developer-chosen mapping from source code to labeled building blocks, exposed as an API, captures enough of the system's semantics that users and LLM agents can audit and control it faithfully.

Editorial extensions

If this is right

  • A developer can make an existing system auditable by adding decorators to the components it chooses to expose, without rewriting the application logic.
  • The same REST API feeds both the user interface and an LLM agent, so an explanation given in conversation refers to the same system state a user can inspect.
  • Control mechanisms become first-class blocks: a user or agent can inspect and edit non-goal filters, divine rule guards, and shutdown triggers with the same interface used to inspect models.
  • Multi-model flows such as ensembles and model multiplicity can be represented explicitly through Splitter and Aggregator blocks, making the aggregation step itself transparent.
  • Tool-augmented language models can use the generated API as their toolset, which is the concrete route by which machine interpretability is aligned with human interpretability.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The strength of the alignment claim depends on the developer's Layer 1 mapping: if blocks are chosen for convenience rather than semantic fidelity, an API can present a tidy structure while hiding the behavior that actually matters.
  • A direct experimental check would be to give an LLM agent only the prototype's REST API and ask it to predict the effect of a control action; the claim stands or falls on whether those predictions match actual system outputs.
  • Nothing in the architecture limits the API to read-only inspection; the same endpoints could be used to enforce invariants automatically, turning the overview into a runtime verification layer.
  • The control-building-block vocabulary could accumulate into a shared library of verified components, so controllability becomes a compositional property rather than a per-application design decision.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper proposes an architectural approach for making interactive AI systems transparent and controllable at the system level, rather than only at the level of individual ML models. The central idea is to represent an interactive AI system as a sequence of structural building blocks (e.g., AI models, control mechanisms such as NonGoalFilter and DivineRuleGuard, and flow components such as Splitter and Aggregator), expose these blocks through a developer-defined REST API, and pair them with visual building blocks (LIME, SHAP, What-If) in a five-layer architecture. The authors argue that the resulting flow and API provide an explicit, shared overview that both human users and LLM-based agents can use to understand, audit, and control system behavior, thereby aligning human and machine interpretability. The paper also presents a prototype based on a heart disease prediction ensemble and explicitly labels the work as preliminary.

Significance. If the central claim were substantiated, the paper would offer a useful architectural pattern for system-level XAI and controllability, extending current model-centric explainability to the entire interactive pipeline. The conceptual organization is clear, the building blocks are grounded in existing literature (e.g., Kieseberg et al. on controllable AI, Kulesza et al. on explanatory debugging), and the inclusion of a prototype suggests the approach is implementable. The paper is also honest in labeling the work preliminary. However, the significance currently rests on an unvalidated assumption: that a developer-chosen mapping from source code to structural building blocks, exposed via a REST API, is sufficient for faithful interpretation and control by users and LLM agents. The paper provides neither a user study, an LLM-agent evaluation, nor a formal argument for this faithfulness. As a result, the strongest claim in the abstract and Section 5 overreaches the available evidence.

major comments (3)
  1. [Section 4, Layer 1] The central claim that the flow and API align human and machine interpretability requires that the developer-defined mapping from source code to structural building blocks preserves the semantics needed for audit and control. However, Section 4 states that the representation is 'purely conceptual' and that 'the developer can choose what (parts of) the system to expose.' This means the API could omit or misrepresent control flow, data transformations, or aggregate behavior. For example, an external agent using the API might not be able to determine when NonGoalFilter rejects an input or how the Aggregator combines model outputs. The paper does not specify invariants or provide an evaluation showing that the API is faithful. A concrete test would be to give independent auditors or LLM agents access only to the API and ask them to predict system behavior on a set of inputs, then compare their answers to the actual system behavior.
  2. [Section 5] The paper explicitly calls the architecture 'preliminary,' yet the abstract claims that the approach 'aligns human and machine interpretability of AI models.' There is no user study, no LLM-agent study, and no formal analysis to support this causal claim. The prototype in Section 4 and Figure 2 demonstrates that such an API can be generated, but it does not show that users or LLM agents actually reach correct conclusions about system behavior from it. The paper should include at least a small-scale evaluation with representative audit and control tasks (e.g., identifying which control block rejected an input, explaining why a prediction was made, overriding an unsafe output) for both human users and LLM agents, or clearly reframe the contribution as a speculative architecture without the alignment claim.
  3. [Section 3.2 and Section 4, Layer 2] The behavioral semantics of the structural building blocks are underspecified, which weakens the claim that the generated API is a sufficient 'communication basis.' For instance, the paper describes NonGoalFilter as a pre-processor that rejects inputs, DivineRuleGuard as a postprocessing override, and Splitter/Aggregator for flow control, but it does not specify how the ordering, conditions, and side effects of these blocks are represented in the API—for example, whether the API exposes rejection events, confidence values, or aggregation weights. Without a defined API contract and a demonstration that it conveys these semantics, the architecture cannot guarantee that an LLM or a user can meaningfully audit the system. The authors should provide a concrete API schema for one of their example building blocks and show how it captures the relevant control behavior.
minor comments (4)
  1. [Introduction and Section 3.1] There are several typos: 'Intelligiblity' in the Section 3.1 heading, 'Weviewexplainability' in the introduction, and 'ShutdownT rigger' in Section 3.2. These should be corrected.
  2. [Section 4, Figure 1] Figure 1 is quite dense. The labels such as 'CRUD (manipulate ensemble)' and the connections between layers are not fully explained in the text. A more detailed legend or an explicit description of the data and control flow in the figure would improve readability.
  3. [Introduction] Anthropic's Model Context Protocol (MCP) is mentioned in the introduction as a similar approach, but the paper never compares it with the proposed architecture. A brief discussion of similarities and differences would help position the contribution relative to this prominent related effort.
  4. [Section 4, Layer 5] The paper states that the API 'can then be integrated as tools for a TALM such as ECHO', but it is unclear how the LLM agent is expected to discover the API endpoints, understand the semantics of each building block, or handle errors. A minimal interaction protocol or example conversation would clarify the intended agent workflow.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation; the architecture is a proposal whose API overview is definitional, and self-citations are only illustrative examples.

full rationale

This paper is a conceptual architecture proposal rather than a derivation, so the circularity patterns that require an equation or a fitted parameter do not apply. The central move—representing an interactive system as developer-decorated structural building blocks and auto-generating a REST API from those definitions—makes the "explicit overview" true by construction, and the paper explicitly concedes the mapping is "purely conceptual" and that "the developer can choose what (parts of) the system to expose" (Section 4, Layer 1). That is a threat to the faithfulness of the claimed human/LLM communication basis, but it is an unsupported empirical assumption, not a circular reduction. The only self-citations, ECHO [26] (Layer 5, "a TALM such as ECHO") and AI-Spectra [7] (related work and future directions), are used as examples or future applications and do not supply the load-bearing premise. The conclusion labels the architecture "preliminary" and lists future evaluations (Section 5), which confirms the absence of validation rather than a hidden equivalence. I therefore find no circular step; score 1 reflects the minor, non-load-bearing presence of the authors' own prior work in the examples.

Assumptions & free parameters 0 free parameters · 4 assumptions · 2 invented entities

The paper introduces no fitted parameters. It relies on domain assumptions about the effectiveness of architectural transparency and the validity of mapping external control mechanisms into the building block framework. The main invented entities are conceptual: the building block vocabulary and the five-layer architecture. No independent evidence is provided beyond the descriptive prototype.

assumptions (4)
  • domain assumption The five control mechanisms from Kieseberg et al. retain their intended behavior when mapped to structural building blocks.
    Section 3.2 maps DivineRuleGuard, NonGoalFilter, ShutdownTrigger, BiasInjector, and LogicBomb from the cited work into the proposed pipeline without re-validation.
  • domain assumption Exposing system components as an API makes the system more interpretable to both humans and LLMs.
    Central claim of the paper in Section 4; not empirically validated.
  • domain assumption LIME and SHAP address Why and Why-not explanations.
    Section 3.1 relies on this established XAI characterization.
  • domain assumption Interactive systems embedding AI can be viewed as type 2 neuro-symbolic systems.
    Section 3 and Section 2 assume this framing.
invented entities (2)
  • Structural building blocks (e.g., DivineRuleGuard, NonGoalFilter, Splitter, Aggregator)
    purpose: To represent system components and control mechanisms as composable, inspectable units in a pipeline.
    Introduced in Section 3.2; borrowed from Kieseberg et al. and extended; no empirical evaluation of their transparency benefit is provided.
  • The 5-layer architecture (structural blocks, API, visual blocks, UI, agents)
    purpose: To organize and expose system structure to users and automated agents.
    Proposed in Section 4; illustrated with a prototype but not validated.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Composable Building Blocks for Controllable and Transparent Interactive AI Systems." pith.science (2026). https://pith.science/paper/UDYOMYAW

@misc{pith2026250602262,
  author       = {Pith},
  title        = {Pith review of: Composable Building Blocks for Controllable and Transparent Interactive AI Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/UDYOMYAW}},
  note         = {Machine review of arXiv:2506.02262}
}
read the original abstract

While the increased integration of AI technologies into interactive systems enables them to solve an equally increasing number of tasks, the black box problem of AI models continues to spread throughout the interactive system as a whole. Explainable AI (XAI) techniques can make AI models more accessible by employing post-hoc methods or transitioning to inherently interpretable models. While this makes individual AI models clearer, the overarching system architecture remains opaque. To this end, we propose an approach to represent interactive systems as sequences of structural building blocks, such as AI models and control mechanisms grounded in the literature. These can then be explained through accompanying visual building blocks, such as XAI techniques. The flow and APIs of the structural building blocks form an explicit overview of the system. This serves as a communication basis for both humans and automated agents like LLMs, aligning human and machine interpretability of AI models. We discuss a selection of building blocks and concretize our flow-based approach in an architecture and accompanying prototype interactive system.

Figures

Figures reproduced from arXiv: 2506.02262 by the authors.

Figure 1
Figure 1. An example heart disease prediction ensemble to illustrate our proposed archi￾tecture. Layer 1 shows the structural building blocks, consisting of our building blocks (in blue) integrated into the ML pipeline (in green). Layer 2 converts the structural building blocks into a callable API, usable by the visual building blocks in layer 3, assembled into the user interface of layer 4. The API is also accessible by the … view at source ↗
Figure 2
Figure 2. Prototype of our approach using the heart disease prediction ensemble. The UI (layer 4) shows each structural building block (layer 1) influencing predictions, exposing system behavior to both users and automated agents (layer 5) through visual building blocks (layer 3) and an API (layer 2), respectively. 5 Conclusion Rising AI complexity has led to an increase in challenges regarding explain￾ing and controlling AI … view at source ↗

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

29 extracted references · 11 canonical work pages

  1. [1]

    In: 2019 IEEE/ACM 41st International Conference on Software En- gineering: Software Engineering in Practice (ICSE-SEIP)

    Amershi, S., Begel, A., Bird, C., DeLine, R., Gall, H., Kamar, E., Nagappan, N., Nushi, B., Zimmermann, T.: Software Engineering for Machine Learning: A Case Study. In: 2019 IEEE/ACM 41st International Conference on Software En- gineering: Software Engineering in Practice (ICSE-SEIP). pp. 291–300 (2019). https://doi.org/10.1109/ICSE-SEIP.2019.00042

    arXiv 2019

  2. [2]

    anthropic.com/news/model-context-protocol

    Anthropic: Introducing the Model Context Protocol (2024), https://www. anthropic.com/news/model-context-protocol

    work page 2024

  3. [3]

    Information Fusion58, 82–115 (2020)

    Barredo Arrieta, A., Díaz-Rodríguez, N., Del Ser, J., Bennetot, A., Tabik, S., Barbado, A., Garcia, S., Gil-Lopez, S., Molina, D., Benjamins, R., Chatila, R., Herrera, F.: Explainable Artificial Intelligence (XAI): Concepts, taxonomies, op- portunities and challenges toward responsible AI. Information Fusion58, 82–115 (2020). https://doi.org/10.1016/j.inf...

    doi:10.1016/j.inffus.2019.12.012 2020

  4. [4]

    7(EICS) (Jun 2023)

    Brie, P., Burny, N., Sluÿters, A., Vanderdonckt, J.: Evaluating a Large Language ModelonSearchingforGUILayouts.Proc.ACMHum.-Comput.Interact. 7(EICS) (Jun 2023). https://doi.org/10.1145/3593230

    work page doi:10.1145/3593230 2023

  5. [6]

    Dix, A., Mayer, S., Palanque, P., Panizzi, E., Spano, L.D.: Engineering Interactive SystemsEmbeddingAITechnologies.In:CompanionProceedingsofthe2023ACM SIGCHI Symposium on Engineering Interactive Computing Systems. p. 90–92. EICS ’23 Companion, Association for Computing Machinery, New York, NY, USA (2023). https://doi.org/10.1145/3596454.3597195

    work page arXiv 2023

  6. [7]

    In: Zaina, L., Campos, J.C., Spano, D., Luyten, K., Palanque, P., van der Veer, G., Ebert, A., Humayoun, S.R., Memmesheimer, V

    Eerlings, G., Vanbrabant, S., Liesenborgs, J., Rovelo Ruiz, G., Vanacken, D., Luyten, K.: AI-Spectra: A Visual Dashboard for Model Multiplicity to Enhance Informed and Transparent Decision-Making. In: Zaina, L., Campos, J.C., Spano, D., Luyten, K., Palanque, P., van der Veer, G., Ebert, A., Humayoun, S.R., Memmesheimer, V. (eds.) Engineering Interactive C...

    work page doi:10.1007/978-3-031-9176 2025

  7. [8]

    Philosophy & Technology34(4), 1607–1622 (Dec 2021)

    von Eschenbach, W.J.: Transparency and the Black Box Problem: Why We Do Not Trust AI. Philosophy & Technology34(4), 1607–1622 (Dec 2021). https:// doi.org/10.1007/s13347-021-00477-0

    doi:10.1007/s13347-021-00477-0 2021

  8. [9]

    Science Robotics4(37), eaay7120 (2019)

    Gunning, D., Stefik, M., Choi, J., Miller, T., Stumpf, S., Yang, G.Z.: XAI—Explainable artificial intelligence. Science Robotics4(37), eaay7120 (2019). https://doi.org/10.1126/scirobotics.aay7120

    doi:10.1126/scirobotics.aay7120 2019

Show all 29 references
  1. [10]

    In: Proceedings of the 30th International Conference on Intelligent User Interfaces

    He, G., Aishwarya, N., Gadiraju, U.: Is Conversational XAI All You Need? Human- AI Decision Making With a Conversational XAI Assistant. In: Proceedings of the 30th International Conference on Intelligent User Interfaces. p. 907–924. IUI ’25, Association for Computing Machinery...

    2025

  2. [11]

    In: 2018 25th Asia-Pacific Software Engineering Conference (APSEC)

    Hu, Q., Ma, L., Zhao, J.: DeepGraph: A PyCharm Tool for Visualizing and Under- standing Deep Learning Models. In: 2018 25th Asia-Pacific Software Engineering Conference (APSEC). pp. 628–632 (2018). https://doi.org/10.1109/APSEC.2018. 00079

    2018 doi

  3. [12]

    Engelmore Memorial Lecture

    Kautz, H.: The Third AI Summer: AAAI Robert S. Engelmore Memorial Lecture. AI Magazine 43(1), 105–125 (Mar 2022). https://doi.org/10.1002/aaai.12036

    2022 doi

  4. [13]

    (eds.) Machine Learning and Knowledge Extraction

    Kieseberg, P., Weippl, E., Tjoa, A.M., Cabitza, F., Campagner, A., Holzinger, A.: Controllable AI - An Alternative to Trustworthiness in Complex AI Systems? In: Holzinger, A., Kieseberg, P., Cabitza, F., Campagner, A., Tjoa, A.M., Weippl, E. (eds.) Machine Learning and Knowled...

    2023 doi

  5. [14]

    In: Proceedings of the 20th International Conference on Intelligent User Interfaces

    Kulesza, T., Burnett, M., Wong, W.K., Stumpf, S.: Principles of Explanatory Debugging to Personalize Interactive Machine Learning. In: Proceedings of the 20th International Conference on Intelligent User Interfaces. p. 126–137. IUI ’15, Association for Computing Machinery, New...

    2015

  6. [15]

    In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems

    Kulesza, T., Stumpf, S., Burnett, M., Kwan, I.: Tell me more? the effects of mental model soundness on personalizing an intelligent agent. In: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems. p. 1–10. CHI ’12, Association for Computing Machinery, New...

    2012

  7. [16]

    In: Proceedings of the 37th International Conference on Neural Information Processing Systems

    Lu,P.,Peng,B.,Cheng,H.,Galley,M.,Chang,K.W.,Wu,Y.N.,Zhu,S.C.,Gao,J.: Chameleon: Plug-and-Play Compositional Reasoning with Large Language Mod- els. In: Proceedings of the 37th International Conference on Neural Information Processing Systems. NIPS ’23, Curran Associates Inc., ...

    2023

  8. [17]

    In: Proceedings of the 31st International Conference on Neural Information Pro- cessing Systems

    Lundberg, S.M., Lee, S.I.: A Unified Approach to Interpreting Model Predictions. In: Proceedings of the 31st International Conference on Neural Information Pro- cessing Systems. p. 4768–4777. NIPS’17, Curran Associates Inc., Red Hook, NY, USA (2017)

    2017

  9. [18]

    Luo, H., Specia, L.: From Understanding to Utilization: A Survey on Explainability for Large Language Models (2024), https://arxiv.org/abs/2401.12874

    2024 arXiv

  10. [19]

    Decision Support Systems 191, 114402 (2025)

    Martens, D., Hinns, J., Dams, C., Vergouwen, M., Evgeniou, T.: Tell me a story! Narrative-driven XAI with Large Language Models. Decision Support Systems 191, 114402 (2025). https://doi.org/10.1016/j.dss.2025.114402

    2025

  11. [20]

    Mavrepis, P., Makridis, G., Fatouros, G., Koukos, V., Separdani, M.M., Kyriazis, D.: XAI for All: Can Large Language Models Simplify Explainable AI? (2024), https://arxiv.org/abs/2401.13110

    2024 arXiv

  12. [21]

    ACM Trans

    Mohseni, S., Zarei, N., Ragan, E.D.: A Multidisciplinary Survey and Framework for Design and Evaluation of Explainable AI Systems. ACM Trans. Interact. Intell. Syst. 11(3–4) (Sep 2021). https://doi.org/10.1145/3387166

    2021 doi

  13. [22]

    Opitz, D., Maclin, R.: Popular ensemble methods: an empirical study. J. Artif. Int. Res. 11(1), 169–198 (Jul 1999)

    1999

  14. [23]

    Parisi, A., Zhao, Y., Fiedel, N.: TALM: Tool Augmented Language Models (2022), https://arxiv.org/abs/2205.12255

    2022 arXiv

  15. [24]

    Why Should I Trust You?

    Ribeiro, M.T., Singh, S., Guestrin, C.: "Why Should I Trust You?": Explaining the Predictions of Any Classifier. In: Proceedings of the 22nd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. p. 1135–1144. KDD ’16, Association for Computing Machinery, ...

    2016

  16. [25]

    In: 2023 IEEE/CVF International Conference on Computer Vi- sion (ICCV)

    Surís, D., Menon, S., Vondrick, C.: ViperGPT: Visual Inference via Python Execu- tion for Reasoning. In: 2023 IEEE/CVF International Conference on Computer Vi- sion (ICCV). pp. 11854–11864 (2023). https://doi.org/10.1109/ICCV51070.2023. 01092

    2023

  17. [26]

    Proc.ACMHum.-Comput.Interact

    Vanbrabant, S., Eerlings, G., Rovelo Ruiz, G., Vanacken, D.: ECHO: Enhanc- ing Conversational Explainable AI through Tool-Augmented Language Models. Proc.ACMHum.-Comput.Interact. 9(EICS)(Jun2025).https://doi.org/10.1145/ 3734191

  18. [27]

    IEEE Transactions on Pattern Analysis and MachineIntelligence 47(2),878–899(2025).https://doi.org/10.1109/TPAMI.2024

    Wang, W., Yang, Y., Wu, F.: Towards Data-And Knowledge-Driven AI: A Sur- vey on Neuro-Symbolic Computing. IEEE Transactions on Pattern Analysis and MachineIntelligence 47(2),878–899(2025).https://doi.org/10.1109/TPAMI.2024. 3483273

    2025 doi

  19. [28]

    In: 2022 IEEE Visualization and Visual Analytics (VIS)

    Wang, Z.J., Zhong, C., Xin, R., Takagi, T., Chen, Z., Chau, D.H., Rudin, C., Seltzer, M.: TimberTrek: Exploring and Curating Sparse Decision Trees with In- teractive Visualization. In: 2022 IEEE Visualization and Visual Analytics (VIS). pp. 60–64 (2022). https://doi.org/10.110...

    2022

  20. [29]

    IEEE Transactions on Visualization and Computer Graphics26(1), 56–65 (2020)

    Wexler, J., Pushkarna, M., Bolukbasi, T., Wattenberg, M., Viégas, F., Wilson, J.: The What-If Tool: Interactive Probing of Machine Learning Models. IEEE Transactions on Visualization and Computer Graphics26(1), 56–65 (2020). https: //doi.org/10.1109/TVCG.2019.2934619

    2020

  21. [30]

    In: Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems

    Xu, X., Yu, A., Jonker, T.R., Todi, K., Lu, F., Qian, X., Evangelista Belo, J.a.M., Wang, T., Li, M., Mun, A., Wu, T.Y., Shen, J., Zhang, T., Kokhlikyan, N., Wang, F., Sorenson, P., Kim, S., Benko, H.: XAIR: A Framework of Explainable AI in Augmented Reality. In: Proceedings o...

    2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.