Setup and Configuration
Catalyst Data: Installation and Configuration
Install, configure, validate, and recover Catalyst Data safely.
Catalyst Data · How-to Guide
Governed entities, indicators, sources, evidence, questions, instruments, datasets, observations, quality, review, query, export, API, access, connectors, and refresh.
Purpose
This guide covers a reversible installation or update of Catalyst Data, including baseline capture, package identity, dependencies, routes, permissions, service health, sample validation, rollback, and documentation handoff.
Prerequisites
- A verified backup
- Administrative or repository access
- The canonical release archive and checksum
- A documented rollback path
- A test workspace and the synthetic sample below
Sample data
This article uses a fictional Resilient Community Retrofit Program. The files contain one demonstration row for every documented feature, so each capability can be tested without private or production data.
Download CSV feature examples · Download JSON workspace example
Preview
| # | Feature | Sample action | Expected result | Classification |
|---|---|---|---|---|
| 1 | Entities | create the Community Center entity | a stable entity ID | synthetic-demo |
| 2 | Indicators | define monthly electricity use with unit, method, and direction | a reusable indicator definition | synthetic-demo |
| 3 | Sources | register utility data with publisher, URL, license, retrieval, and citation | a provenance source record | synthetic-demo |
| 4 | Evidence Ledger | attach a bill and meter export to observations | an evidence chain | synthetic-demo |
| 5 | Questions | state whether use fell after weather normalization | a bounded analytical question | synthetic-demo |
The downloadable files include all 20 feature rows.
Procedure
1. Capture the baseline
- Record the installed interface, backend, package, and schema versions.
- Export or back up product-owned state.
- Record canonical routes, shortcodes, service URLs, repository branch, and environment variables.
- Check for incomplete migrations or uncommitted changes.
2. Install or update
- Verify the archive root, manifest, checksum, and version identity.
- Install through the product-supported WordPress, package, or service path.
- Run syntax, structure, contract, and product tests before replacing the working release.
- Apply database or schema migrations only after the backup is confirmed.
- Start or refresh the backend and verify its health response.
3. Configure
- Set documented endpoints and secret references; never store secret values in public code.
- Assign least-privilege roles and product ownership.
- Confirm product, version, component, issue, release, collection, and article-type context where supported.
- Clear only the caches affected by changed assets or routes.
4. Validate
- Import the feature-example CSV or JSON.
- Test every feature row in a nonproduction workspace.
- Compare actual results with the expected_result field.
- Reopen state after a clean reload.
- Record differences as draft support issues before enabling real use.
Expected output
- One consistent product version across interface, service, manifest, package, and export
- Healthy routes and dependencies
- A complete synthetic feature test
- A verified backup and rollback point
- No credentials or private data in public artifacts
Verification
- PHP, Python, R, JavaScript, or package checks pass where applicable.
- The product loads in an incognito or clean session.
- The sample data can be created, saved, reopened, exported, and removed.
- Permissions prevent unauthorized administrative or private access.
- The previous release can be restored.
Responsible use
Governed data is not automatically true or fit for every purpose; preserve source rights, privacy, definitions, uncertainty, and review.
Do not delete backups or the prior working release until the installed version and all sample features have been validated.
