Configuration as Code

Kiket treats every workspace configuration as source-controlled code. Definition repositories (usually GitHub/GitLab repos) store the .kiket/ directory that describes workflows, boards, agents, automations, dashboards, and extensions.

Repository Layout

.kiket/
  projects/
  workflows/
  boards/
  analytics/
  agents/
  extensions/
  automation_recipes/

• Projects – project manifests define metadata, default boards, and access policies.
• Workflows – YAML files describing states, transitions, approvals, and automation hooks.
• Boards – Kanban or table layouts with saved queries.
• Analytics – dashboard and query definitions plus dbt overlays.
• Agents – agent manifests + prompt templates that power AI experiences.
• Extensions – manifest stubs that connect remote services to the workspace.

Validation Pipeline

1. Configuration Loader ingests the repo via webhook or manual sync.
2. Schema validation checks every file (model version, required keys, duplicates).
3. Dependency validation ensures referenced workflows/boards/projects exist.
4. Activation publishes definitions to the workspace after all checks pass.

Validation errors surface in the UI, CLI (kiket config sync), and API responses with actionable messages so teams can fix issues before activating a new revision.

Promotion & Rollback

• Create branches for experimental workflows.
• Use pull requests to review .kiket/ changes just like application code.
• The platform stores every activated revision, so you can roll back if a workflow misbehaves.

Treating configuration as code keeps workflows auditable, testable, and consistent across environments.