Testing, release, and agent oversight

Verification asks what evidence supports a claim that the system behaves as intended. In legal engineering, that claim has several parts: the software routes correctly, the information remains traceable, the legal method is appropriate, and the designated person can make an informed decision.

No single test establishes all of them.

Test at different boundaries

A result can pass schema validation and still contain an unsupported proposition. A human may approve a sensible memo while the software stores it under the wrong matter. Design evidence for both kinds of failure.

View the relationship model (Mermaid)

flowchart TB
    R["Requirement and decision criteria"] --> U["Logic and schema checks"]
    R --> I["Integration and workflow checks"]
    R --> H["Domain review and user evaluation"]
    U --> E["Release evidence<br/>Known version, cases, results, limitations"]
    I --> E
    H --> E
    E --> O["Operational observation"]
    O -->|New cases and failures| R

Continuous integration is a feedback mechanism

Continuous integration means integrating changes frequently and checking them automatically. A CI workflow might validate manifests, run routing tests, build packages, and check that diagrams still render.

This reduces the time between introducing a defect and noticing it. It does not replace review, and a green check proves only that the configured checks passed. If code and tests share the same misunderstanding, they can agree with each other while violating the intended requirement.

Delivery and deployment are different

Continuous delivery keeps a change ready for release after the required checks. Continuous deployment automatically releases qualifying changes. A team can use automated builds and tests while keeping an explicit human release decision.

View the relationship model

flowchart TB
    C["Reviewed change"] --> B["Build and automated checks"]
    B --> S["Staging or representative test environment"]
    S --> V["Verify release evidence"]
    V --> A["Authorized release decision"]
    A --> P["Production deployment"]
    P --> M["Observe and verify"]
    M -->|Failure| R["Rollback or controlled correction"]

This is a proposed controlled release pattern, not a claim that the local toolkit includes hosted staging or an unattended production service. The implementation described in this guide is local and session-driven.

AI changes the review problem

AI can draft tests, code, diagrams, and documentation. It can also spread one mistaken assumption across all four. Ask for tests derived from the intended behavior and important counterexamples, not only from the generated implementation.

Fast generation can leave several maintenance problems behind: code that needs repair, a system its maintainers cannot explain, weak evidence of correctness, or stale instructions and tool configurations. Review needs to address each of these, rather than counting completed tasks alone.

View the relationship model

flowchart TB
    D["Choose a bounded delegation"] --> C["Define constraints and permitted tools"]
    C --> A["Agent produces a change or result"]
    A --> E["Collect independent evidence"]
    E --> H["Human review at the required boundary"]
    H --> K["Accept, revise, or reject"]
    K --> L["Record the decision and update shared knowledge"]

Review effort should reflect consequences, uncertainty, and reversibility. A formatting edit and a change to approval routing deserve different scrutiny. The important record is what was delegated, under which constraints, what evidence came back, and who accepted responsibility for the result.