Setup and Configuration
Catalyst Analytics R: Installation and Configuration
Install, configure, validate, and recover Catalyst Analytics R safely.
Catalyst Analytics R · How-to Guide
Reproducible R data intake, metadata, validation, indicators, comparison, uncertainty, sensitivity, stress, accounting, workspaces, snapshots, reports, and export.
Purpose
This guide covers a reversible installation or update of Catalyst Analytics R, 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 | Data Intake | read the feature-example CSV or JSON | a governed R data object | synthetic-demo |
| 2 | Source Metadata | attach publisher, URL, license, citation, retrieval, field, and unit metadata | a source-aware dataset | synthetic-demo |
| 3 | Dataset Validation | check required fields, types, missingness, units, and duplicates | a validation report | synthetic-demo |
| 4 | Indicator Registry | register annual energy savings | a reusable indicator definition | synthetic-demo |
| 5 | Derived Indicators | calculate baseline minus retrofit kWh | derived values with method metadata | synthetic-demo |
The downloadable files include all 16 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
Statistical output requires method competence, source review, uncertainty communication, and domain interpretation; it is not automatic causal proof.
Do not delete backups or the prior working release until the installed version and all sample features have been validated.
