Enterprise Governance
In Lesson 9, you installed the IDFA plugin. Every analyst who installs idfa-financial-architect gets identical enforcement of the four technical guardrails — Named Range naming, layer isolation, LaTeX verification, Intent Notes, and Delegated Calculation. The plugin solved the consistency problem. Now solve the accountability problem.
Enforcement is not governance. The plugin ensures every agent-built formula uses Inp_ prefixes and Named Range notation. But the plugin cannot tell you which models exist in the organisation, who owns them, when they were last validated, or who approved the last structural change. Enterprise governance is what turns plugin-enforced technical compliance into organisational capability. This lesson builds the four artefacts that a CFO signs off on — the organisational layer around the plugin's enforcement layer.
What the Plugin Handles vs What Governance Handles
| Plugin Enforces (Technical) | Governance Handles (Organisational) |
|---|---|
Inp_ naming convention | Who approves exceptions to conventions |
| Layer isolation rules | Who validates a model before a board meeting |
| Intent Note format | Coverage tracking — what % of models are compliant |
| LaTeX verification for complex formulas | Session log retention — where stored, how long |
| Delegated Calculation for all calculations | Named Range modification approval — who signs off |
| Agent Decision Table workflows | Model Registry — which models exist, who owns them |
| Sector prefixes — which prefix your team uses | |
| Validation scheduling — quarterly reviews, re-validation triggers | |
| Plugin version management — when to update, who approves |
The plugin is the enforcement layer. Governance is the accountability layer. Together they produce a finance function where every model is compliant by construction (plugin) and tracked by management (governance).
The Four Governance Artefacts
Every IDFA deployment beyond a single analyst requires four written documents. Each one addresses a different failure mode — and each one covers what the plugin cannot.
| Artefact | Failure It Prevents | Owner | Review Cycle |
|---|---|---|---|
| Standards Document | Inconsistent conventions beyond plugin defaults | Finance Director | Annual |
| Model Registry | Models lost, duplicated, or unvalidated | Controller | Quarterly |
| Validation Protocol | Non-compliant models used in board or regulatory contexts | Controller | Per model, before use |
| Agent Standards Policy | AI agents modifying models without organisational controls | CTO / Controller | Annual |
1. The IDFA Standards Document
The plugin's SKILL.md already defines the base standard — Inp_ prefixes, three-layer isolation, LaTeX verification for WACC/NPV/DCF/IRR, Intent Note format, and Delegated Calculation. Your Standards Document specifies everything the plugin does not cover:
Sector extensions. Which domain prefix does your team use? If you are in investment banking, your Standards Document specifies IB_ as the prefix. The plugin enforces Inp_ for assumptions but does not know which sector prefix to apply. The Standards Document fills this gap.
Exception and override process. The plugin enforces Named Range Priority with zero tolerance. But real organisations encounter edge cases — a legacy formula that cannot be converted without breaking a regulatory filing, a temporary override for a time-sensitive analysis. The Standards Document specifies: who can approve an exception, how the exception is documented, and when it expires.
Organisation-specific additions. Your team may require LaTeX verification for formulas beyond the four the plugin enforces (WACC, NPV, DCF, IRR). Debt schedules, waterfall distributions, carried interest calculations — the Standards Document extends the plugin's LaTeX list with your team's specific requirements.
Plugin version policy. Which version of idfa-financial-architect is approved for production use? When a new version is released, who evaluates it, who approves the upgrade, and what is the rollout timeline? The Standards Document governs the governance tool itself.
The Standards Document is not a duplicate of the SKILL.md. It is the addendum — everything your organisation needs that the plugin does not provide out of the box.
2. The Model Registry
The Model Registry is a centralised record of every IDFA-compliant model in the organisation. The plugin ensures every model it touches is built correctly. The Registry answers the question the plugin cannot: "How many models do we have, who owns them, and when was each one last validated?"
Required fields:
| Field | Description | Example |
|---|---|---|
| Model Name | Descriptive name following naming standard | Q4 2026 Revenue Forecast |
| Owner | Analyst responsible for maintenance | J. Chen |
| Last Validation Date | Date of most recent formal validation | 2026-09-15 |
| Intent Note Coverage % | AI-generated formulas with Intent Notes / total AI-generated formulas | 94% |
| Model Link | Path or URL to the model file | /finance/models/q4-2026-rev.xlsx |
Intent Note Coverage % is the key compliance metric. It answers: "Of the formulas in this model that were generated by an AI agent, what percentage have documented Intent Notes?" A model at 100% coverage has a complete audit trail for every AI-generated formula. A model at 60% coverage has gaps — formulas whose business intent is undocumented.
The Controller reviews the registry quarterly. Models with coverage below the team's threshold (commonly 90%) are flagged for remediation. Models not validated within the past six months are flagged for re-validation.
3. The Validation Protocol
The plugin automates guardrail enforcement during model building — every formula the agent writes uses Named Ranges, complex formulas get LaTeX verification, and Intent Notes are attached. The Validation Protocol is the gate BEFORE a model enters production: a formal checklist that goes beyond what the plugin checks in real time.
The four validation checks:
-
Named Range compliance. Run the plugin's compliance check across the entire model. Confirm every formula in the Calculations layer uses Named Ranges only — zero coordinate references. The plugin enforces this during building; the Protocol confirms it across the complete model.
-
LaTeX verification. Every complex formula (WACC, NPV, Terminal Value, IRR, and any others specified in the Standards Document) has LaTeX verification documented. Compare the LaTeX expression to the Excel formula and confirm they match.
-
Intent Note completeness. Verify Intent Note coverage % against the team's threshold. Every AI-generated formula must have an Intent Note in the prescribed format. Document the coverage percentage in the Registry.
-
Output accuracy. Run the model on a standard set of test inputs. Compare outputs to expected values. If any output deviates from expectation, trace the formula chain to identify the source of the discrepancy.
Validation results are documented and attached to the model entry in the Registry. A model that fails any check is not cleared for the intended use until the failure is corrected and re-validated.
4. Finance Domain Agent Standards Policy
The plugin enforces Delegated Calculation, guardrails, and the Agent Decision Table. The Policy governs what the plugin cannot:
Named Range modification approval workflow. The plugin allows agents to read Named Range values and write to Named Range inputs — this is normal What-If analysis. But modifying Named Range definitions — renaming a range, deleting a range, or changing which cell a range points to — changes the model's structural skeleton. The Policy specifies: who approves structural modifications (typically the Controller), how the approval is documented, and what happens if an unapproved modification is detected.
Session log retention. Every agent session that interacts with an IDFA model must produce a log retained for at least 90 days. The log must include: which model was accessed, which Named Ranges were read or written, which formulas were generated, and the Intent Notes attached. The plugin produces the session data; the Policy specifies where it is stored, how long it is kept, and who can access it.
Production deployment gating. The Policy defines what "production" means — board presentations, regulatory filings, external stakeholder reports — and specifies that no model reaches production without passing the Validation Protocol. The plugin ensures quality during building; the Policy gates the transition from draft to production.
Plugin version management. When the Panaversity team releases a new version of the IDFA plugin, the Policy specifies: who evaluates the update, who approves the rollout, and what the timeline is for updating all team installations. This prevents version fragmentation where some analysts run v1.0 and others run v1.1 with different guardrail behaviour.
In Cowork, you can customise the installed IDFA plugin for your team's specific needs. Click Customize on the plugin to open a refinement session where you can adjust the SKILL.md — adding sector-specific prefixes, extending the LaTeX-required formula list, or tightening naming conventions. Any refinements should be documented in the Standards Document so the organisational layer stays aligned with the technical layer. See the Cowork plugin refinement guide for details.
Sector-Specific Naming Extensions
When an organisation operates across multiple financial domains — investment banking, private equity, FP&A, treasury, credit — models from different domains may use the same variable names for different concepts. Entry_Multiple in an investment banking context means EV/EBITDA entry multiple; in a private equity context it means the purchase price multiple for an LBO. Without domain prefixes, these collide in multi-domain models and consolidated reports.
The naming extension adds a domain prefix before the standard IDFA name:
| Domain | Prefix | Example Named Ranges |
|---|---|---|
| Investment Banking | IB_ | IB_EV_Entry, IB_LBO_IRR |
| Private Equity | PE_ | PE_Entry_Multiple, PE_MOIC |
| FP&A / Corporate | FP_ | FP_Budget_Rev_Y1, FP_Variance |
| Treasury | TR_ | TR_FX_Hedge_Ratio, TR_DSO |
| Credit / Risk | CR_ | CR_PD_Rating, CR_DSCR |
These prefixes are optional for single-domain teams but recommended for any organisation where models from different domains appear in the same reporting context. Include your chosen prefixes in the Standards Document.
Exercise: Design the Organisational Layer
You already have the IDFA plugin enforcing the technical guardrails. Now design the organisational layer that the plugin cannot provide.
Step 1. Draft a Standards Document addendum covering:
- Sector prefix for your domain (or "none" if single-domain)
- Exception process: who approves, how documented, when it expires
- Additional LaTeX-required formulas beyond WACC, NPV, DCF, IRR
- Plugin version policy: approved version, upgrade evaluation process
Step 2. Create a Model Registry template with all five required fields. Add a column for "Status" (Active / Archived / Under Review) and a column for "Next Validation Due."
Step 3. Write the Validation Protocol as a checklist — four checks, each with a Pass/Fail field and a Notes field for documenting findings.
Step 4. Draft the Agent Standards Policy covering: Named Range modification approval workflow, session log retention (where stored, how long, who accesses), production deployment gating (what counts as "production"), and plugin version management (who evaluates updates, rollout timeline).
The Business Bottom Line
A CFO evaluating IDFA governance sees four measurable returns:
Audit duration compresses. When every formula reads as a business rule and every AI-generated formula carries an Intent Note, auditors can verify model logic by reading — not by tracing cell references. Weeks of audit preparation compress to days.
Analyst onboarding drops. A new analyst inheriting an IDFA-compliant model with a Standards Document can understand the model structure immediately. The naming conventions, layer rules, and Intent Notes eliminate the months-long process of reconstructing the original builder's mental model.
Regulatory confidence increases. Models that pass the Validation Protocol have documented compliance: zero coordinate references, LaTeX-verified complex formulas, complete Intent Notes, and accurate outputs against test inputs. This is the evidence base that regulators require.
Institutional memory compounds. Intent Notes are the organisational memory that survives staff turnover. Every formula documents not just what it calculates but why it was designed that way. This memory does not leave when the analyst leaves.
The plugin handles enforcement. Governance handles accountability. Together they produce a finance function where every model is compliant by construction and tracked by management.
Try With AI
Open Cowork or Claude Code. Ensure the IDFA plugin is installed. In Claude Code: /plugin marketplace add panaversity/agentfactory-business-plugins then /plugin install idfa-financial-architect@agentfactory-business. In Cowork: install via Customize → Browse plugins. You will design governance artefacts using AI as a drafting partner.
Prompt 1 — Draft a Standards Document addendum:
Your team uses the IDFA plugin (idfa-financial-architect).
The plugin enforces naming conventions, layer isolation, LaTeX
verification, Intent Notes, and Delegated Calculation. Draft a Standards
Document that covers what the plugin does NOT enforce:
1. Sector prefix — we are in [YOUR DOMAIN]. Which prefix (IB_, PE_,
FP_, TR_, CR_) applies? How do we handle variables that span
domains?
2. Exception process — who approves an exception to a guardrail?
How is the exception documented? When does it expire?
3. Extended LaTeX list — beyond WACC, NPV, DCF Terminal Value,
and IRR, which formulas specific to [YOUR DOMAIN] require
LaTeX verification?
4. Plugin version policy — which version is approved for production?
Who evaluates new releases? What is the rollout timeline?
Format it as a document a CFO could review and approve.
What you are learning: How to design the organisational layer around a technical enforcement tool. The skill is not writing the naming convention — the plugin handles that. The skill is specifying everything the plugin cannot: sector extensions, exception processes, version governance, and domain-specific additions.
Prompt 2 — Design a Model Registry:
Design a Model Registry template for tracking IDFA-compliant
financial models. The IDFA plugin enforces guardrails during
building — the Registry tracks models across the organisation.
Include these columns:
- Model Name
- Owner (analyst responsible)
- Last Validation Date
- Intent Note Coverage % (AI-generated formulas with Intent Notes
/ total AI-generated formulas)
- Model Link (file path or URL)
- Status (Active / Archived / Under Review)
- Next Validation Due
Then create a Quarterly Review Checklist that the Controller uses
to review the registry. Include checks for: models with coverage
below 90%, models not validated in 6+ months, models with no
designated owner, and models marked Under Review for more than
one quarter.
What you are learning: How to design a tracking system that makes compliance measurable. The plugin ensures quality during building; the Registry ensures visibility across the organisation. The Coverage % metric is particularly important — it quantifies the gap between full compliance and current state.
Prompt 3 — Write an Agent Standards Policy:
Draft a Finance Domain Agent Standards Policy for a team that
uses the IDFA plugin (idfa-financial-architect).
The plugin already enforces the four technical guardrails.
This policy covers what the plugin cannot:
1. Named Range Modification Approval — agents may read and write
values but may not modify Named Range definitions without
Controller approval. Specify the approval workflow.
2. Session Log Retention — 90-day minimum. Specify what the log
must contain and where it is stored.
3. Production Deployment Gating — define what "production" means
(board presentations, regulatory filings, external reports)
and specify that Validation Protocol must pass first.
4. Plugin Version Management — who evaluates new plugin releases,
who approves the upgrade, and what is the rollout timeline.
Format it as a policy document with numbered requirements that
can be referenced in compliance reviews.
What you are learning: How to write policy that governs the organisational boundaries around automated enforcement. The plugin handles the technical rules; the policy handles accountability, approval, retention, and version control. Writing this policy exercises your understanding of the boundary between what automation can enforce and what humans must govern.
Flashcards Study Aid
Next: Lesson 11: The Five Capabilities — Capstone — where you validate all five Finance Domain Agent capabilities on the model you have built throughout this chapter.