Sustainable Catalyst Platform Architecture and Product Taxonomy

1. Purpose

This document defines the current Sustainable Catalyst platform architecture and the vocabulary used to distinguish institutional environments, public products, shared services, specialized modules, domain packs, and experimental capabilities.

2. Architectural principle

Sustainable Catalyst is designed as a connected research-to-decision environment rather than a pile of unrelated tools. Products retain distinct responsibilities while exchanging records through shared identifiers, schemas, provenance, source links, and export contracts.

3. Institutional environments

• Knowledge Library: the source, document, citation, relationship, discovery, and preservation environment.
• Sustainable Catalyst Lab: the scientific and engineering research environment for notebooks, experiments, datasets, observations, instruments, and reproducible runs.
• Platform: the connected application environment that joins routing, public intelligence, analysis, experimentation, and decision support.
• Advisory: the separately governed applied-services environment used only through formal engagements.

4. Five connected public products

1. Research Librarian finds the appropriate route through site content, methods, repositories, data, and tools.
2. Lab investigates questions through scientific and engineering research records.
3. Site Intelligence observes public systems through source-aware country, regional, thematic, geospatial, and temporal evidence.
4. Workbench calculates, models, codes, graphs, builds, and validates.
5. Decision Studio synthesizes evidence, alternatives, tradeoffs, reviews, and outcomes into auditable decision artifacts.

5. Shared platform layers

• Platform Core: identity, access, schemas, APIs, artifact envelopes, provenance, security, integrations, and shared services.
• Knowledge and evidence layer: source records, citations, claims, quotations, collections, relationships, and integrity metadata.
• Methodology and trust layer: evaluation, limitations, validation, responsible-use rules, and public accountability records.
• Participation and support layer: Feature Suggestions, known issues, support knowledge, feedback, and roadmap intelligence.
• Publishing and export layer: HTML records, PDFs, datasets, bundles, briefs, embeds, and public APIs.

6. Specialized modules

Modules implement focused workflows inside or across products. Catalyst Canvas supports problem framing and experiment design. Narrative Risk structures claims, evidence, confidence, and time. Catalyst Data provides shared relational concepts for entities, sources, indicators, periods, and measurements. Catalyst Finance supports incentives, distribution, pricing, and tradeoff analysis. Global Impact Catalyst supports sustainability indicators and scenarios. Catalyst Grit explores self-directed resilience and recovery records with explicit ethical limits.

A module should not be described as the entire platform. Its documentation must state where it runs, what records it consumes and produces, and whether it is current, experimental, historical, or integrated into another product.

7. Domain packs and capability families

Domain packs extend a core product with specialized calculators, methods, schemas, datasets, or interfaces. Examples include scientific disciplines, engineering domains, economics, geospatial analysis, hardware, or observatory themes. They inherit the governing requirements of the host product and institution.

8. Typed artifact exchange

A cross-product artifact should preserve at minimum: source product, product version, artifact type, artifact identifier, schema version, creation time, method, source references, freshness, confidence or validation state, and transformation history. Products may add fields but should not silently discard these core elements.

9. Integration rules

• The source product remains identifiable after import.
• Imported artifacts are not treated as verified merely because another Sustainable Catalyst product produced them.
• Transformations create a new record or a visible revision.
• Unavailable services should degrade honestly rather than presenting fabricated completeness.
• Public APIs and embeds should preserve status, method, and source information appropriate to the context.

10. Data and persistence

Each product may have its own operational store, but shared records should use stable identifiers and common contracts. Platform Core may coordinate identity and exchange; the Knowledge Library preserves durable knowledge records; product databases manage operational state.

11. Deployment and offline boundaries

Products may run as WordPress integrations, browser applications, backend services, local or offline tools, public APIs, or repository examples. Deployment differences must not obscure product version, data origin, availability, or privacy behavior.

12. Product status vocabulary

• Current: maintained and part of the active platform.
• Experimental: available for testing without production reliability claims.
• Domain pack: focused capability hosted by a core product.
• Shared service: infrastructure used by multiple products.
• Historical: preserved but not part of the current architecture.
• Planned: documented roadmap work not represented as available.

13. Architecture review

Architecture documentation should be reviewed whenever a new core product, shared identity model, cross-product contract, public API, persistent workspace, or major governance boundary is introduced.

Revision History