Rethinking the CarbonGraph journey: from models to outcomes
Author:
Luke Boivin
CarbonGraph has grown around a powerful core: building connected life cycle models. As the range of people and work supported by the platform expands, we’re taking a step back to think about the overall experience—from the moment someone enters CarbonGraph to the moment they share a result or complete a deliverable.
This is an early design exploration, not a finished product specification. We’ve built an interactive prototype so you can experience the ideas directly, see how the pieces fit together, and help us decide what’s worth pursuing.
What we’re trying to improve
Environmental assessment work rarely ends with a model. Teams may need to collect source files, collaborate with subject-matter experts, test scenarios, prepare an EPD, publish a dashboard, or give a colleague a safe way to explore results.
Today, those activities can feel like separate tasks organized around the model itself. We’re exploring a journey that better reflects the different layers of the work:
Build reliable models that can be reused across products and projects.
Organize work around a specific goal or deliverable.
Keep the relevant models, files, methods, context, and outputs together.
Let AI assist with the work while remaining grounded in that context.
Give each person access to the experience they need without exposing unnecessary complexity.
A clearer distinction between Models and Projects
The central idea in this prototype is a clearer separation between Models and Projects.
Models are reusable systems. They live independently, can evolve over time, and can be referenced wherever they’re needed. A model may still be a draft, or it may have one or more committed versions that other work can rely on.
Projects are organized around an outcome. A project brings together committed model versions, files, workflow context, AI skills, and outputs for a specific goal—such as producing an EPD, completing a product carbon footprint, or comparing scenarios.
The intent is to make both kinds of work easier to understand. Modelers retain a durable modeling environment, while the broader team gets a workspace organized around what they’re trying to accomplish.
Try the interactive prototype below
This prototype combines several workflows into one connected experience. It uses sample data, and some actions are illustrative, but most of the primary cards, breadcrumbs, menus, buttons, and dropdowns are interactive.
As you explore, try the following:
Start on Home and compare the options for building a Model and starting a Project.
Open Models and look at how folders, drafts, and committed versions are represented.
Create or open a Project and see how its goal establishes a starting workflow without locking the team into it.
Add a committed model version, files, and AI skills to the Project.
Open the model, switch variants, and explore the navigation for modeling, analysis, and sharing.
Return to the Project and explore its outputs, including the dashboard and EPD document.
Preview the dashboard as an Analyst and notice which parts of the underlying work are intentionally hidden.
Open the Project agent and consider how an AI assistant could work with the Project’s models, files, results, and context.
What this design is proposing
Start from intent
The home experience asks a simple question: are you building a reusable system, or are you working toward a particular outcome?
For someone encountering CarbonGraph for the first time, a short guided tutorial can show how these two concepts connect—from building a model to using it in a project and sharing the resulting work.
Let models evolve independently
Models don’t need a “complete” state. They can remain drafts while they’re being edited, then be committed as stable versions.
A Project references a committed version so its results remain reproducible, even as the underlying model continues to evolve.
Give projects enough context to guide the work
A Project goal can suggest an initial workflow, method, indicators, steps, and relevant AI skills.
These are intended to be useful starting points rather than rigid templates. The team can edit them as the work develops.
Treat results and deliverables as first-class outputs
Dashboards, calculation results, scenario comparisons, reports, exports, and EPD documents live together as Project outputs.
Their statuses make it easier to understand what is current, what is still a draft, what has been published, and what may need to be rerun after the underlying work changes.
Adapt the experience to the audience
An analyst may need to explore a published dashboard without opening the graph, source files, workflow configuration, or modeling tools behind it.
The prototype explores a focused, read-only analyst experience alongside the full environment used by modelers and editors.
Make the agent part of the workflow
Rather than treating AI as a separate destination, the agent is available throughout the product.
Its context changes with the work. At the Project level, it can understand the relevant models, files, results, goal, and workflow. Within the model, it can assist with more focused modeling tasks.
Where we’d value your feedback
We’re less interested in whether every label or visual detail is perfect today. The more important question is whether the overall structure matches how you think about your work.
As you explore, consider:
Models and Projects: Does this distinction feel natural? Where would you hesitate about where something belongs?
Starting work: Would you know whether to begin with a Model or a Project? What information would help you decide?
Project workflow: Does bringing models, files, methods, skills, and outputs together make the work easier to understand? What feels missing or unnecessary?
Versions and variants: Is it clear which model version a Project is using and how variants relate to it?
Outputs: Do the output types and statuses help you understand what has been produced, what is ready to share, and what may be out of date?
Different users: Does the analyst experience provide enough information to be useful while keeping the modeling complexity out of the way?
AI assistance: Where would an agent be genuinely useful in this journey? Where would you want more control, review, or transparency?
Overall journey: What felt most intuitive, and where did you become uncertain or lose the thread?
Help us shape what comes next
Please spend a few minutes clicking through the prototype and share your reaction.
Screenshots and notes tied to a specific moment are especially helpful. Even a short comment such as “I expected this button to…” gives us something concrete to learn from.
We’ll use this feedback to refine the overall product structure, prioritize the workflows that provide the most value, and decide what should move from prototype into implementation.