ChangeLock: Approval-First AI Automation

• 

  ChangeLock: Approval-First AI Automation

• 

  Pipeline History

• 

  Jobs

Inspiration

AI is changing how software gets written, reviewed, and maintained. Developers can use AI-assisted tools to analyze code, propose fixes, and accelerate engineering workflows. But as the ability to generate changes becomes faster, an equally important question emerges:

How do we ensure that the action being executed is exactly the action that a human authorized?

An approval should not be treated as a permanent, unrestricted permission. A patch can change after review. The target commit can move. Action parameters can differ from those originally approved. An authorization can expire. If a workflow fails to account for these changes, an earlier approval may no longer represent the intent of the person who granted it.

We wanted to explore a different approach to software automation: one where authorization is explicit, tied to evidence about the proposed action, and checked at the moment it matters.

That idea became ChangeLock.

ChangeLock is built around a simple principle: automation should move quickly, but authorization must remain precise. Instead of treating human approval as a checkbox in a workflow, ChangeLock models it as a verifiable boundary between proposing a change and allowing an action to proceed.

What it does

ChangeLock is an approval-first software delivery project built around GitLab workflows. It focuses on validating authorization for proposed software changes before execution.

Its central concept is evidence-bound approval: an approval is associated with the specific details that define the authorized action.

The design considers four critical elements:

• Patch fingerprint: A SHA-256 fingerprint helps identify the exact patch that was reviewed.
• Target commit: The approval is associated with the intended commit, helping detect when the underlying target changes.
• Action parameters: Authorization is tied to the parameters of the proposed action rather than being treated as generic permission.
• Expiry: An approval has a validity period and should not remain usable indefinitely.

Before an action proceeds, these details provide the basis for checking whether the approval still represents the intended authorization. If the patch changes, the target commit no longer matches, or the approval expires, the earlier approval should not be accepted as valid for the changed circumstances.

The project is organized around components with distinct responsibilities:

• ApprovalController handles approval-related control and validation.
• MRAnalyzer supports merge request analysis.
• PatchGenerator supports proposed patch generation.
• ActionExecutor is responsible for action execution.
• AuditLog supports recording workflow decisions and outcomes.
• WorkflowDashboard and WorkflowDetail provide the frontend experience for inspecting workflow information.

Together, these components express the project's core idea: separate the proposal, authorization, validation, and execution concerns so that the workflow can be inspected rather than treated as a black box.

ChangeLock's value is not simply that it adds another approval step. It is that it aims to preserve the relationship between what was reviewed, what was authorized, and what is allowed to proceed.

How we built it

We built ChangeLock as a web application with a Python and Flask backend and a React and TypeScript frontend. The backend is supported by a database layer using SQLAlchemy and SQLite, while the frontend provides the interface for exploring workflow information.

The implementation is organized into components so that approval control, merge request analysis, patch generation, execution, and audit logging have distinct responsibilities. This separation makes the authorization model easier to reason about and gives the project a clearer foundation for testing and future extension.

GitLab is central to the project's development and integration context. The repository includes application code, project documentation, merge request history, and CI/CD configuration. The documented integration operations include retrieving merge request details and diffs, checking commit information and pipeline status, accessing file content, and posting analysis results or proposed patches as merge request comments.

We also invested in making the development process inspectable. The repository's merge request history records work on backend testing, security checks, OpenTelemetry instrumentation, and project readiness. The CI/CD pipeline provides a repeatable mechanism for running configured checks, while job logs help explain what ran and where a failure occurred.

Rather than presenting the application as an opaque demonstration, we wanted its implementation and development process to be available for review. The repository and its configuration give reviewers a starting point for understanding how the project is organized and how its checks are performed.

The result is a project that brings together an explicit authorization model, a modular application structure, and a GitLab-oriented development workflow.

Challenges we ran into

One of the central challenges was defining what an approval actually means.

In a simple workflow, an approval can look like a boolean value: approved or not approved. But that representation leaves an important question unanswered: approved for exactly what?

A useful authorization model needs to distinguish the action that was reviewed from any action that may be attempted later. This led us to focus on the patch fingerprint, target commit, action parameters, and expiry as part of the approval model.

Another challenge was keeping the different parts of the application aligned. Approval control, merge request analysis, patch generation, execution, and audit logging must work together without losing sight of the action being authorized. Separating these responsibilities helps clarify the design, but it also introduces integration and testing requirements.

Security and reproducibility presented another challenge. A project can have a compelling interface and a well-described architecture without having sufficient evidence that its behavior is reliable. CI checks, dependency management, security scanning, and readable logs are important because they help expose implementation problems instead of hiding them.

Dependency compatibility also required attention. The OpenTelemetry instrumentation introduced dependencies that needed to remain compatible with the application and its tests. This reinforced an important engineering lesson: adding an observability component is not just a matter of importing a library; the dependency set and runtime integration must work together.

Finally, we had to distinguish the project's intended safety properties from the evidence available to demonstrate them. A design can specify that stale approvals should be rejected, but a convincing demonstration should also show the corresponding implementation and test or execution evidence. Keeping that distinction clear is essential for a security-oriented project.

These challenges shaped the way we approached ChangeLock: define the authorization boundary carefully, keep the implementation inspectable, and make verification an important part of the development process.

Accomplishments that we're proud of

We are proud of turning an important software automation concern into a concrete engineering project with an explicit design principle: an approval should authorize a specific action, not grant an open-ended permission to act.

The project's most distinctive contribution is its evidence-bound approval model, which considers the patch fingerprint, target commit, action parameters, and expiry together. This gives the system a clear basis for evaluating whether an authorization still matches the action under consideration.

We are also proud of the modular architecture. By separating approval control, merge request analysis, patch generation, execution, and audit logging, ChangeLock makes its key responsibilities easier to inspect and reason about.

The GitLab repository provides additional evidence of the development process. Its merged merge requests document work on backend testing, security-related CI checks, OpenTelemetry instrumentation, and project readiness. The CI/CD configuration and job logs help make the validation process visible to reviewers.

Equally important, the project has helped us think beyond whether an automated action can be performed. It asks whether the action was authorized correctly, whether that authorization remains valid, and whether the workflow can be examined afterward.

That shift in perspective is the accomplishment we value most: treating authorization as a first-class engineering concern in AI-assisted software delivery.

What we learned

The most important lesson we learned is that automation and authorization are different problems.

Generating a patch or identifying a potential fix is only one part of a software workflow. Before an action proceeds, the system must also establish that the proposed action matches what was authorized. That requires a more precise model than a generic approval flag.

We learned to think about approvals as evidence tied to a particular context. Patch identity, target commit, action parameters, and expiry each address a different way in which the relationship between approval and action can become invalid.

We also learned that security properties must be demonstrated, not merely described. Tests can establish behavior under defined conditions; logs can expose execution details; CI pipelines can make configured checks repeatable; and documentation can help reviewers understand how to reproduce them. Each provides a different kind of evidence, and none should be presented as proof of something it does not establish.

Building with GitLab also reinforced the importance of development discipline. Merge requests, automated checks, security scanning, dependency compatibility, and readable job logs are not administrative details separate from engineering quality. They are part of making software maintainable and reviewable.

Finally, we learned that good automation should make its boundaries visible. A system is easier to trust when reviewers can understand what it is designed to do, what conditions it checks, what its current limitations are, and what evidence supports its claims.

What's next for ChangeLock: Approval-First AI Automation

Our next priority is to strengthen the connection between ChangeLock's authorization model and verifiable end-to-end behavior.

We want to expand the automated test coverage for approval creation, successful validation, expired approvals, changed patch fingerprints, mismatched target commits, and altered action parameters. These tests should make the intended safety properties explicit and provide repeatable evidence of how the system responds when authorization conditions are no longer satisfied.

We also want to improve the visibility of execution outcomes. A reviewer should be able to follow a proposed action through its authorization decision, validation result, execution status, and corresponding audit information without having to infer what happened from disconnected screens or logs.

Further work can improve the workflow dashboard, reduce unnecessary polling, strengthen error handling, and make the setup and reproduction process clearer. Additional GitLab integration can be developed incrementally, with each new capability accompanied by appropriate validation and evidence.

Multi-approval workflows and deeper automation integrations are also potential future directions. These would need to preserve the same principle that guides the current design: authorization must remain explicit, appropriately scoped, and verifiable.

ChangeLock is not about giving automation unlimited freedom. It is about creating a clearer boundary between the speed of AI-assisted development and the accountability required for software delivery.

Our vision is a development workflow where automation can move quickly because authorization is precise, changes are verifiable, and decisions remain inspectable.

ChangeLock — Approve deliberately. Validate continuously. Execute accountably.

Built With

• ai-assisted-development
• approval-workflows
• audit-logging
• automated-testing
• devsecops
• flask
• gitlab
• gitlab-api
• gitlab-ci-cd
• gitlab-duo
• gitlab-duo-agent-platform
• human-in-the-loop
• jwt
• merge-requests
• opentelemetry
• pytest
• python
• react
• rest-api
• sha-256
• software-security
• sqlalchemy
• sqlite
• typescript
• workflow-automation