"Compliance by Design" — Git workflows as financial controls

[Priyanshu-Priyam]

Problem

Teams evaluating AI agents in regulated industries (fintech, banking, insurance)
typically assume they need to bolt on compliance controls after building the agent.
This creates friction at adoption — security reviews, audit evidence requirements,
and segregation-of-duties policies all feel like blockers.

Observation

While exploring GitAgent after the launch, I noticed something that I don't think
is obvious from the developer tooling angle:

Financial controls and git workflows are structurally identical:

Finance Control	GitAgent Equivalent
Maker-checker approval	Pull Request merge
Segregation of Duties (SOD)	Branch protection rules
Immutable audit trail	git log
Control documentation	RULES.md
Point-in-time snapshot	git tag

These are isomorphisms. A GitAgent-standard agent operating
inside a git repo doesn't need to be "made compliant" ; it already is, by how git works.
Compliance isn't layered on. It's a property of the architecture.

Proof of Concept

I built a working demo applying this to the CFO office , specifically the monthly
financial close (bank reconciliation, AP sub-ledger, variance commentary):

→ https://github.com/Priyanshu-Priyam/gitclose

Three agents (Atlas, Nova, Echo) close the books for a fictional engineering firm.
Every agent action is a git commit. Every approval is a merged PR. The audit trail
is git log. No separate compliance layer. No documentation overhead.

Proposed Addition

Would it be worth adding a section to the GitAgent docs or README on regulated
industry use cases? The core argument being: if your domain has maker-checker
controls, audit requirements, and recurring exceptions, GitAgent is already
structurally compatible ; you don't need to retrofit compliance on top.

Happy to contribute a write-up or worked example if that's useful.

[shreyas-lyzr]

Review

Great issue @Priyanshu-Priyam — the isomorphism table (maker-checker ↔ PR merge, SOD ↔ branch protection, audit trail ↔ git log) is a genuinely useful framing.

Looked through gitclose — the three-agent structure (Atlas/Nova/Echo) with proper gitagent-style directories (agent.yaml, SOUL.md, RULES.md, DUTIES.md, tools/, hooks/, memory/) is solid. The agents use permissions.cannot lists, escalation thresholds, and hooks for pre-tool-use validation — which maps directly to our compliance spec.

A few observations:

What works well

• The demo makes the "compliance by design" argument concrete — every agent action is a commit, every approval is a PR merge, the audit trail is git log. That's not theoretical, it's structural.
• The agent.yaml files use escalation.threshold_amount and permissions.cannot: [post_journal_entry, approve_own_work] which is exactly how SOD should work in practice.
• The traditional-workflow comparison (SharePoint folders, email chains, Excel versioning) vs git-native is compelling.

What to address

1. agent.yaml schema — gitclose's agent.yaml uses fields not in the gitagent spec (identity, permissions, escalation, schedule). These are good ideas but would need schema additions or should live in metadata. Worth a separate RFC if you want these standardized.
2. Skills format — The skills files (e.g. skills/bank_reconciliation.md) don't use the SKILL.md frontmatter format (name, description, allowed-tools). Would need the --- YAML frontmatter block to pass gitagent validate.
3. spec_version missing — agent.yaml should include spec_version: "0.1.0" per the spec.

On the docs proposal

Yes — a "Regulated Industries" section in the docs would be valuable. The framing should be:

If your domain already has maker-checker controls, audit requirements, and exception workflows, gitagent's git-native architecture provides these as structural properties — not bolted-on compliance layers.

Would welcome a PR with:

• A docs section (could be docs/regulated-industries.md or a README section)
• gitclose as a linked example
• The isomorphism table from this issue

Nice work building the demo first before proposing the docs — that's the right order.

[Priyanshu-Priyam]

Thank you @shreyas-lyzr !
Have added a PR with proposed changes implemented.

#44