Skip to main content
Platinur is a hosted product. You sign in to your Platinur workspace and Platinur operates the control plane, worker, and Evidence services on your behalf. The control plane is the operator UI and API. The worker performs source loading, dbt runs, Evidence rebuilds, assistant validation, and scheduled orchestration work.

​
Runtime services

  • Control plane: the portal UI, API, metadata, settings, promotions, and run summaries.
  • Worker: managed source actions, dbt execution, Evidence rebuild requests, Assistant runtime, and bounded tools.
  • Shared dashboard builder: serializes heavy Evidence compilation across accounts and reuses cached compiler artifacts, avoiding one build container per concurrent account.
  • Shared connector and REST-egress broker: pins and validates customer-configurable REST traffic, blocks private/metadata peers, keeps partner-platform credentials outside tenant containers, and supports already-configured legacy or future certified partner operations. It is not an ELT engine, does not add Airbyte to the v1 new-source catalog, and no Airbyte runtime is installed locally.
  • Data warehouse: the analytics runtime. Each workspace binds one ClickHouse for its lifetime. Connect uses a customer-owned service; Managed uses a dedicated service provisioned and administered by Platinur at the capacity selected during signup. Raw and governed data stay in that bound warehouse. See Connect Your Data Warehouse.
  • dbt Core: transformations from selected source schemas into staging, warehouse, and marts layers.
  • Evidence: dashboard project and preview service.
  • GitHub: governed promotion boundary between Staging and Prod.
  • AI: powers the assistant and model generation. Platform-supported OpenAI capacity is included with every workspace; you can optionally add your own OpenAI key, which then takes precedence.
Each workspace container can access only its own workspace and the exact read-only Unix sockets it needs. Shared policy, credentials, coordination databases, and other customer workspaces remain on the host. Platinur publishes a single account-bound runtime-policy snapshot containing only that workspace’s effective AI limits and entitlements; missing or mismatched policy fails closed.

​
Source-to-production path

  1. Data lands in the bound warehouse through Platinur Integrations or an external customer process.
  2. The operator selects schemas and tables in the Build tab of Models.
  3. The guided first build—investigation, persisted business interview, generation, and validation—commits a governed change to Staging.
  4. Promotions exposes its files, diff, validation, ancestry, and dependency-aware Undo.
  5. Prepare release selects a dependency-closed set of Staging changes, an editable PR title, and optional description. Platinur validates the release and survivor states, publishes an exact branch from Production through GitHub, then reconstructs independent work that remains in Staging.
  6. Production syncs from the configured production branch and runs dbt/Evidence refreshes as separate observable work.
  7. Monitoring is the complete operational ledger for successful, failed, and in-flight executions; Issues tracks unresolved failures and Audit records human configuration changes.

​
Metadata model

Platinur stores product-owned metadata in the portal database: users, sessions, audit events, source state, run summaries, proposals, validation status, promotion state, and compact references to external artifacts. Detailed tool artifacts remain owned by dbt, Evidence, GitHub, and the bound warehouse; scheduling runs in-process in the worker.

​
What Platinur does and does not store

Your warehouse data stays in your bound warehouse — Platinur reads and writes it through the connection you supply, but does not copy raw data elsewhere. Platinur’s own state is limited to the metadata above plus the generated dbt and Evidence project files, which are version-controlled in your connected GitHub repository.