# Governed Data Delivery

Git-versioned configuration, DTAP environments, role-based access, and run monitoring: data delivery your team can audit and repeat.

## Solutions · Governed data delivery — Delivery you can audit, repeat, and trust.

Commit configuration changes to Git, run them under role-based access, and keep development, test, acceptance, and production apart, each with its own source and platform credentials.

Links: [Join the waitlist](/waitlist/)

## Versioned by default

Pipeline configuration (the project file with its sources, data platform, and jobs, the contracts, and SQL template overrides) is committed to Git, where every change is a diff. Credentials, members, and roles stay in the control plane.

## DTAP environments

Keep development, test, acceptance, and production apart, each with its own source and platform credentials.

## Observable runs

Follow a run through its checkpoints to where it stopped, and watch success rate and p95 duration over 24 hours, 7 days, or 30 days. Monitoring covers the development environment today.

## How it works — Change management your auditors will recognize.

- **Configure in Git**: Edits in the app stay in a working copy until you commit them, and a commit goes straight to the Git branch bound to the environment. From there it is diffable and revertible like any other commit; the app opens no pull request. Until an environment has a deployed commit, a run uses the latest saved edits instead.
- **Separate DTAP environments**: Development, test, acceptance, and production are separate environments, each with its own credentials. There is no promotion step in the app yet: changes move between them through your Git repository.
- **Observe your runs**: Each run shows its status, what it moved, and, for a step that failed, a classified error and hint; the full error stays in the agent's log. Metrics across runs show whether your jobs in development are healthy.

## Governance without the friction.

Role-based access separates who manages the organization, who configures and runs pipelines, and who only observes. Credentials live in a vault project of their own per organization, the agent moves your records on your infrastructure, and changes to projects, environments, data platforms, sources, jobs, schedules, and contracts are recorded in an audit log that owners and admins can read. The contracts, and the docs Amfelt generates when you switch them on, sit in the same Git repository for your AI tools to read; a governed endpoint for AI tools is on the roadmap (see AI-ready data).

Links: [AI-ready data](/solutions/ai-ready-data/)

## From the blog — Stop asking AI to guess. Make your pipelines deterministic.

Pipelines must reproduce, not predict. Where deterministic ingestion belongs, where LLMs actually help, and why blurring the line is how data projects quietly go wrong.

Links: [Read the article](/blog/make-your-pipelines-deterministic/)

## FAQ — Common questions.

### How does role-based access work?

Rank roles (owner, admin, operator, viewer) govern who manages the organization, who runs data operations, and who observes. A separate billing-only role is on the roadmap.

### Where are credentials stored?

In a project of its own per organization in Amfelt's vault, reached through a machine identity scoped to that project. The agent resolves credentials through the control plane at run time, and Amfelt strips them from everything it commits to Git. For an agent without a control plane, `amfelt add-target --store-login-in-file` keeps a target's login in the local project file instead, and `amfelt commit` refuses to push that file.

### Can I roll back a bad change?

Yes, for configuration. From an environment's history in the app you can restore its jobs, runs, and contracts to an earlier commit; sources and the data platform stay as they are. Data already loaded into history stays as it is.

## Ship data changes like software.

Join the waitlist to hear when Amfelt opens to more teams.

Links: [Join the waitlist](/waitlist/)