3  From Q-CRAFT to the LIC-DSF

What you need to know:

  • Q-CRAFT is a proof of concept for a larger goal: making the LIC-DSF more usable through human-centered design
  • The biggest barrier to effective fiscal projection tools is ergonomics, not economics
  • We are looking for co-design partners, not endorsements

3.1 The real barrier: ergonomics, not economics

The biggest barrier to effective use of fiscal projection tools is not the economics. It is the ergonomics. Smart people struggle not because the methodology is too complex, but because the tools do not guide them through the decisions they need to make.

This observation has emerged from years of conversations with MoF economists, central bank staff, and IFI economists. It has inspired a more organized human-centered design approach: structured design sprints and organized discussions with practitioners who use these tools in their daily work.

3.2 What we built and what we proved

Q-CRAFT Explorer reimplements the IMF’s Q-CRAFT Excel workbook as an open-source Python web application. The calculation engine is a standalone package with automated parity tests against the original Excel tool.

We are building a comprehensive, public, automated testing pipeline to ensure parity with the Excel model. So far we have tested well over 140 countries on baseline fiscal metrics across a variety of parameter combinations. Results have been strong: 0.0 percentage-point difference across the board. We continue to expand the test suite. This kind of transparent, automated verification is essential for tools where the stakes are higher.

3.3 Q-CRAFT is the proof of concept

Q-CRAFT is deliberately small: five user-facing parameters, one core equation. We chose it because it demonstrates the approach in miniature.

The real goal is the LIC-DSF, the Low-Income Country Debt Sustainability Framework. The LIC-DSF modeling chain (Q-CRAFT, DIGNAD, LIC-DSF) is far more complex, far more consequential, and used for every low-income country. We are already working with end-users of the LIC-DSF, and we want to work with its designers too.

3.4 A modular engine, multiple interfaces

flowchart TB
    E["Q-CRAFT<br>Engine"] --> W["Web Explorer<br>(current)"]
    E --> G["Guided Analysis<br>(planned)"]
    E --> D["DSF Integration<br>(goal)"]

    style E fill:#1ABC9C,stroke:#2C3E50,color:#fff
    style W fill:#ECF0F1,stroke:#2C3E50
    style G fill:#ECF0F1,stroke:#2C3E50,stroke-dasharray: 5 5
    style D fill:#ECF0F1,stroke:#2C3E50,stroke-dasharray: 5 5

One engine, multiple interfaces

The same engine powers different front-ends for different needs:

  1. Web Explorer (current). Interactive charts for quick country analysis. Select a country, adjust parameters, compare scenarios.
  2. Guided Analysis Tool (planned). AI-assisted reasoning through input assumptions. Always available, cheaper than a technical assistance mission. Helps users understand what to enter and why.
  3. DSF Integration (the goal). Q-CRAFT and DIGNAD feeding into LIC-DSF assumptions, with the same ergonomic layer applied to a far more consequential tool.

The current process makes it hard to do things the right way. Documentation is separated from implementation. If you do not know what to enter for a parameter, you search the user guide and hope it is there (and often it is not). The goal is design that makes it easy to do the right thing and hard to do the wrong thing.

3.5 The co-design invitation

We built V1. Here are specific areas where practitioner input shapes V2.

  1. Parameter guidance. How should we help users choose productivity growth, expenditure rigidity, and debt target values? What heuristics do experienced practitioners use?
  2. Default assumptions. What are sensible defaults by country type? Should defaults vary by region?
  3. Capacity development integration. How would this tool fit into an actual CD workshop or IMF mission?
  4. Validation priorities. Which countries and scenarios should we prioritize for verification?
  5. Missing features. What is the first thing you would want that is not here?

What we are asking for: a few hours from a few people for design feedback, continued communication so we build credibly, and feedback on whether we are making something useful.

What we are NOT asking for: official endorsement (we understand institutional constraints), access to confidential information (we work with publicly available materials), or money (this is grant-funded, MIT-licensed open source).

3.6 Why start here

Two reasons to start with Q-CRAFT:

  1. Immediate value. A co-designed Q-CRAFT tool could be in use within weeks. It costs nothing and requires minimal commitment to evaluate. It complements, not replaces, the Excel workbook.
  2. Pioneer the approach. Success with Q-CRAFT builds trust and methodology for the LIC-DSF. We prove the design process works on a small tool before applying it to the one that matters most.

3.7 The SovTech vision

Central banks have been applying technology to supervisory functions for years. The BIS documented “SupTech generations” as a framework for technology-driven supervisory and regulatory solutions. The question is no longer whether such tools belong in public financial institutions. The question is when sovereign debt management will catch up.

We call this SovTech: the application of SupTech principles to sovereign debt analysis. Three principles guide this work:

Modularity that respects how people work. Same engine, different interfaces. Components like building blocks: swap one module without rebuilding everything.

Open source as institutional infrastructure. Transparency means anyone can examine how analysis is done. MIT license, no barriers to adoption. The calculation engine and the interface are separate concerns, developed and tested independently.

AI as enabler, with a trust layer. The cost of building analytical software has dropped dramatically. But sovereign debt analysis serves policy decisions worth billions of dollars. Verification pipelines, automated testing, and human-in-the-loop governance are requirements, not optional features. This is why we built the parity verification pipeline described in Part 1.

Q-CRAFT Explorer is our attempt to show what this looks like. The source code is on GitHub. We welcome your input.