Allowed
When: An assured Scope 2 update.
Your code: The disclosure publishes, and the record keeps the facts and the rule version.
Who picks it up: The Business Owner sees reporting progress. Auditors read the record inside an engagement.
GRC & Enterprise Risk · TypeScript SDK
Test your disclosure rules before an agent publishes a number
Your drafting agent prepares a Scope 3 update. Before it publishes, the TypeScript SDK checks the disclosure against your rules on assurance, completeness, and restatements. You can test that path locally before connecting anything.
TypeScript: a local test for the stop
VeriproofTestHarness returns the decision you queue and makes no network requests. Here it checks that a stopped disclosure never calls publishDisclosure.
TypeScript · @veriproof/sdk-core
import { VeriproofTestHarness } from '@veriproof/sdk-core/testing';
const publishDisclosure = vi.fn();
const local = new VeriproofTestHarness().respondWith({
verdict: 'deny',
reasonCode: 'assurance_missing',
});
const result = await local.veriproof.govern(
'disclosure.publish',
{ disclosureId: 'FY25-S3' },
publishDisclosure,
{
facts: {
disclosure_type: 'scope3_emissions',
target_framework: 'csrd_esrs',
reported_value_delta_pct: -34,
third_party_assurance_obtained: false,
data_completeness_pct: 92,
restatement_of_prior: false,
reviewer_signoff_present: true,
},
},
);
expect(result.status).toBe('blocked');
expect(publishDisclosure).not.toHaveBeenCalled();When you connect, replace the harness with Veriproof.fromEnv(). The facts and the assertions stay the same.
Why TypeScript here: Reporting portals and publishing workflows often run on Node.js, and the SDK’s test harness drops into the test runner you already use.
Disclosure facts for the publication rule
The disclosure simulator sends these. Assurance and sign-off usually come from your GRC platform.
| Fact | What it holds |
|---|---|
disclosure_type | scope1_emissions, scope2_emissions, scope3_emissions, dei_metrics, or climate_risk_narrative. |
target_framework | csrd_esrs or gri. |
reported_value_delta_pct | Change from the previously reported figure. |
third_party_assurance_obtained | True when external assurance covers the figure. |
data_completeness_pct | Share of the underlying data that’s complete. |
restatement_of_prior | True when the update changes a figure you already reported. |
reviewer_signoff_present | True when the reviewer has signed off. |
Publish, review, or hold
Three sample disclosures from the simulator. Run disclosure simulator
Sent to a person
When: The update restates a figure from an earlier report.
Your code: Publication waits for the disclosure committee.
Who picks it up: The disclosure committee member with that authority, in the VeriProof Inbox, by email, or in Slack or Microsoft Teams, with reminders and escalation.
Stopped
When: Scope 3 emissions fell 34%, and there’s no external assurance.
Your code: The status is blocked, and nothing publishes.
Who picks it up: The Governance Engineer sees the assurance rule that held it.
Restatements are their own case
A change to a figure you already reported isn’t the same as a new figure. Send restatement_of_prior so the rule can route those to the disclosure committee instead of treating them like any other update.
Adding to the disclosure rules
Developer fix request
If the committee adds a rule on the calculation method and your agent doesn’t send it, the Developer gets a fix request naming the field.
Changing the rule
Changing the size of change that needs assurance can run in Shadow against real drafts first. For production, an administrator or compliance officer approves the engineer’s version.
Resources
For your business owner
The GRC page explains what the agent can take on and how its decisions are defended.
Read the GRC business caseDocs
Install @veriproof/sdk-core, configure the key, and look up industry values for GRC & Enterprise Risk.
See who handles a restatement
Try the demo portal as the committee reviewer, then as the Governance Engineer who owns the rule.