Recast

External authority via WebMCP at the release gate.

Comment

Recast

The repository says it’s fine. External authority says it isn’t. Recast knows the difference.

AI agents are getting very good at changing software. Passing the repository’s own checks does not mean the change meets requirements owned somewhere else.

Recast retrieves those external requirements at verification time through native WebMCP and checks the change against them. It also consumes independent advisory analysis through MCP. There is no WebMCP-to-MCP bridge. The surfaces stay separate, and the authoritative contract remains outside the repository being changed.

For this submission we show the boundary with a design contract: the feature works, but it violates rules owned by Northfold. An agent repairs only the permitted CSS, verification runs again against the externally retrieved contract, and a human still approves the verified candidate.

The goal is not to make an agent incapable of producing bad output. The goal is to make bad output incapable of passing the release gate unnoticed.

What it does

Recast is a supervised release-governance workflow built around GitLab Duo Agent Platform and GitLab CI/CD.

It separates five responsibilities:

  • Northfold Journal owns the design authority. It exposes its contract through native WebMCP, independently of the application repository.
  • The application contains the implementation. A semantic binding manifest maps CSS selectors and properties to named design roles. Its CSS implements those roles; Northfold determines their required values.
  • Recast Verifier performs verification. Its pipeline and graders live in a separate project. It runs functional checks, retrieves and validates the external contract, checks governed CSS declarations, and distinguishes authoritative violations from advisory findings.
  • SwatchDog MCP contributes independent advice. Its findings can inform repair, but they do not define Northfold’s requirements.
  • GitLab Duo performs the repair. A human starts the custom repair flow. Duo edits and pushes changes without per-edit approval, after which the candidate undergoes verification.

The workflow ends at a separate manual approval job. In the demonstration, a human approved the verified candidate.

WebMCP exposes external authority. MCP contributes advisory evidence. GitLab coordinates repair, verification, and approval.

How we built it

We created a journal-page candidate with a small “Field Notes” label above a card title. The feature worked, but the card used a deliberately generic light theme: different colours, fonts, spacing, rounded corners, and a badge treatment for the label.

The functional checks passed. Verification against Northfold’s external contract did not.

Before repair:

  • Functional verification: PASS
  • Governed CSS conformance: FAIL
  • Authoritative findings: 23
  • Advisory hints: 10

Those authoritative findings covered the card’s role values and literal styling declarations, including the label.

A human initiated the custom Recast repair flow. GitLab Duo updated the role values, removed conflicting literal styling, and committed and pushed the repair. The repair diff changed only src/feature.css and left the semantic bindings unchanged.

Duo’s push automatically triggered the next pipeline. Verification against the same frozen Recast Verifier revision reported:

  • Functional verification: PASS
  • Repair scope: PASSED
  • Governed CSS conformance: PASS
  • Authoritative findings: 0
  • Advisory hints remaining: 0

The scope check compared the repaired candidate against the recorded pre-repair baseline and confirmed that only src/feature.css changed. Duo also adjusted an advisory spacing value, leaving no advisory findings in the final report.

The pipeline waited at release:approve. A human approved the verified candidate, and the job recorded the candidate’s commit, Northfold contract version 2026.10.3, the fetched contract’s SHA-256 fingerprint, and the passing repair-scope result.

This run explicitly requested and enforced contract version 2026.10.3. It recorded the fetched contract’s SHA-256 fingerprint but did not enforce a preselected content hash. The demonstrated endpoint was candidate approval, rather than a deployment or creation of a GitLab Release.

The agent repairs. The system verifies. The human approves.

Challenges we ran into

The most revealing failure happened during an earlier development run.

All 23 authoritative violations had been resolved, but a SwatchDog spacing suggestion still blocked the candidate. We had connected the services successfully, yet our gate policy had failed to preserve the distinction between their outputs.

We corrected the policy: Northfold’s requirements determine design conformance, while SwatchDog’s suggestions remain visible without blocking approval. Required verification failures still stop progression.

We also replaced an authorship-based repair-scope check with a comparison against an explicitly recorded pre-repair commit. In the public demonstration, that check passed and confirmed that the resulting repair changed only src/feature.css.

Accomplishments that we're proud of

We turned an architectural idea into a working workflow across native WebMCP, MCP, GitLab Duo, and GitLab CI/CD.

The demonstration shows a functionally correct candidate failing externally defined requirements, an agent repairing the implementation, and separate verification confirming conformance. The workflow preserves the distinction between authoritative requirements and nonbinding advisory evidence.

Northfold retained ownership of the contract throughout. The application was changed to satisfy that contract, and a human approved the verified result.

What we learned

Connecting independent systems is only part of the problem. Their outputs have to retain their meaning.

A requirement and a suggestion can describe the same property while carrying different authority. Treating both as blocking findings would erase that distinction.

Recast verifies governed CSS declarations at source level. It does not establish complete visual correctness, inspect rendered pixels, or provide adversarial containment of the repair agent. The application’s CI include remains editable, and the manual approval job is not restricted to a designated approver group. Within that scope, it demonstrates that the authoritative requirements can remain external to the repository being modified.

Interoperability should connect independent systems while preserving who decides what is acceptable.

What's next for Recast

We want to test this approach with other externally owned requirements and across multiple independently governed products.

We also want to strengthen repair-scope verification and make the evidence easier to inspect: which requirements were applied, what the agent changed, which checks passed, and who approved the candidate.

Recast. External authority at the release gate.

Built With

  • chrome-devtools-protocol
  • gitlab-ci/cd
  • gitlab-duo-agent-platform
  • google-cloud-run
  • model-context-protocol
  • node.js
  • webmcp
Share this project:

Updates

Submission history