From coordinated work to evidence-bound engineering

From coordinated work to evidence-bound engineering

Coordination tells us who worked on what.

Verification can tell us whether an output is sufficiently grounded.

Action governance can decide whether a particular operation should be allowed to execute.

But for demanding engineering projects, there is still another question:

What exact evidence supports the resulting codebase and the decisions made about it?

That is where the optional integration with RIGOR-FOUNDRY enters the architecture.

https://github.com/anulum/rigor-foundry

The repository itself becomes evidence-bound

RIGOR-FOUNDRY starts from the exact Git-tracked state rather than an informal description of the project.

Audit candidates are bound to concrete repository evidence — for example, an exact blob and line span, or an exact tree and tracked-content digest for repository-wide conditions.

The report therefore carries enough provenance to answer questions such as:

• Which repository state was actually inspected?

• Which exact file or tree did this finding refer to?

• Has the repository changed since the evidence was generated?

• Was the policy or rule set the same?

• Can the result still be reproduced or reviewed later?

This matters because an audit result that cannot be tied back to the exact state it evaluated rapidly becomes ambiguous.

A finding is not automatically a defect

This is a deliberate design choice.

Static rules, model outputs and heuristics can identify things that deserve attention.

They should not automatically be treated as final engineering truth.

RIGOR-FOUNDRY therefore treats findings as review candidates.

A match can remain needs-evidence, be reviewed, accepted, rejected, promoted, or become part of a remediation plan depending on the evidence and policy around it.

Missing evidence does not silently become a pass.

And stale evidence is rejected rather than being reused against a changed repository.

Independent review can be part of the workflow

For more demanding projects, one model or one reviewer should not necessarily be the sole authority.

RIGOR can support independent audit campaigns and preserve disagreement rather than collapsing multiple reviewers into one synthetic answer.

That makes it possible to ask:

Did independent reviewers reach the same conclusion?
If not, where exactly did they disagree?
What evidence would resolve the disagreement?

This is especially useful when AI agents themselves participate in review.

Remediation remains controlled

The objective is not an autonomous loop that discovers a warning and immediately rewrites the codebase.

Evidence can instead feed an explicit remediation process:

candidate → evidence → review → decision → remediation → verification

That creates a much stronger engineering boundary between detecting something suspicious and authorising a change.

Why this complements SYNAPSE

SYNAPSE and RIGOR solve different parts of the problem.

SYNAPSE provides the coordination provenance:
who participated, who owned the work, which task was active, how responsibility moved, and what happened across the shared workflow.

RIGOR provides repository and review provenance:
what exact code state was evaluated, what evidence supported a finding, what reviewers decided, and what remediation followed.

The integration therefore moves the system from merely coordinating AI-generated engineering work toward making that work more reviewable and reproducible.

A useful way to describe the combined lifecycle is:

coordinate
→ establish authority
→ execute
→ bind evidence
→ review independently
→ remediate
→ verify

This matters most when quality requirements rise

For a small experimental project, this level of machinery may be unnecessary.

For a complex scientific, infrastructure, safety-sensitive or long-lived engineering program, however, “the agents produced code, and the tests passed” may not be a sufficient standard.

The higher the required level of quality and control, the more valuable it becomes to retain not only the final code, but also the evidence explaining why that code was accepted.

RIGOR-FOUNDRY:

https://github.com/anulum/rigor-foundry