Authoring Overview
Qarion's Authoring area brings hands-on technical work into the same governed space as catalog, quality, and collaboration workflows. Use it when teams need to write or review executable notebooks, pipeline definitions, dbt-style transform models, or package and OCI artifacts without moving governance context out of Qarion.
Authoring Surfaces
| Surface | Use it for |
|---|---|
| Notebooks | Python notebook files, text files, Git-backed analysis workspaces, and executable notebook workers. |
| Pipeline Authoring | Pipeline definition drafts, generated code, repository-backed files, validation, and publication. |
| Transform Models | dbt-style model editing, previews, macros, packages, and project publication. |
| Artifact Repositories | Private Python package repositories, OCI repositories, Docker images, Helm charts, and model artifacts. |
Review And Execution Controls
Authoring surfaces keep executable work reviewable before it leaves Qarion:
- Pipeline Authoring uses plan approval, task checklist gates, generated-file review, generation-readiness gates, command approval, validation, and publication history.
- Transform Models runs previews and dbt-style jobs through approved query connectors, execution profiles, package policies, and safe environment variable handling.
- Notebooks run through kernel profiles or dedicated workers with resource classes, quota enforcement, and lifecycle state tracking.
When an operation needs package or data access, configure the workspace and runtime controls first rather than embedding credentials or ad hoc commands in draft files.
Administrators can monitor the operational side of these controls in AI Ops, Notebook Workers, platform settings, and artifact repository settings. Users should treat blocked validation, missing package access, stale reviews, and worker startup failures as governance signals rather than copy work out of the workspace.
Workspace Sharing
Notebook, Pipeline Authoring, and Transform Model workspaces use the same sharing model:
- Space workspaces are visible to everyone with access to the space.
- Private workspaces are limited to the owner and space administrators.
- Shared workspaces are visible to the owner plus selected people or teams.
Workspace grants support view and manage access. Use view when someone
needs to inspect files or outputs, and manage when they should be able to
change workspace settings, repository bindings, or sharing.
Query Access
Authoring workspaces can be linked to approved query connectors. Linked connectors let notebooks, pipeline previews, and transform previews execute against governed data sources without giving the author broad connector access. Keep connector grants narrow and align them with the workspace purpose.
Do not store source credentials, package tokens, or private index credentials in draft files, notebook cells, profile overrides, or generated support files. Use connectors, artifact repositories, and platform settings so access remains auditable.
Related Guides
- Notebook Workers for administrators monitoring executable notebook runtime capacity.
- AI Ops for Pipeline Authoring readiness and failure signals.
- Source Systems for managing query connectors.
- Pipelines and Orchestration for runtime pipeline visibility after publication.