Developer fix request
Say the firm adds a rule on how long the partner has served the client. If your agent doesn’t send that field, the Developer gets a fix request naming it.
Professional Services · Python SDK
Check independence before an intake agent accepts the work
Your intake agent scopes new client work and proposes acceptance. The Python SDK checks the firm’s independence and conflicts rules first, so acceptance depends on the rules, not on the agent’s reading of them.
Accept, review, or stop
Three sample engagements from the simulator. Run engagement simulator
Allowed
When: A routine, low-risk advisory engagement for a private company.
Your code: The engagement is accepted, and the record keeps the independence facts and the rule version.
Who picks it up: The Business Owner sees intake moving. Auditors read the record inside an engagement.
Sent to a person
When: The client accounts for 19% of office revenue.
Your code: Acceptance waits for independence review.
Who picks it up: The independence reviewer with that authority, in the VeriProof Inbox, by email, or in Slack or Microsoft Teams, with reminders and escalation.
Stopped
When: An audit for a client that receives prohibited non-audit services.
Your code: The status is
blocked, and the engagement isn’t accepted.Who picks it up: The Governance Engineer sees the independence rule that stopped it.
Independence facts for acceptance
The engagement simulator sends these fields. Most come from your independence and conflicts systems.
| Fact | What it holds |
|---|---|
engagement_type | financial_statement_audit, advisory, tax_compliance, or transaction_diligence. |
client_is_public_company | True for a listed client. |
prohibited_nas_active | True when the firm provides prohibited non-audit services to the client. |
fee_dependency_pct | The client’s share of office revenue. |
client_risk_rating | low, moderate, or high. |
conflicts_check_clear | True when the conflicts check is clear. |
partner_signoff_present | True when the engagement partner has signed off. |
Send fee dependence as a number
Pass fee_dependency_pct as the percentage, not a yes or no. The threshold then lives in the rule, where you can try a new value in Shadow before it enforces.
Python: accept inside one client context
async with closes the client when the intake job ends.
Python · veriproof-sdk
from veriproof_sdk import Veriproof
async def accept_engagement(engagement, client):
async with Veriproof.from_env() as vp:
result = await vp.govern(
"engagement.accept",
{"engagementId": engagement.id},
lambda context: practice_system.accept(context.input),
facts={
"engagement_type": engagement.type,
"client_is_public_company": client.is_public,
"prohibited_nas_active": independence.prohibited_services_active(client.id),
"fee_dependency_pct": finance.fee_share_pct(client.id),
"client_risk_rating": client.risk_rating,
"conflicts_check_clear": conflicts.is_clear(engagement.id),
"partner_signoff_present": engagement.partner_signed_off,
},
)
return resultThe caller checks result.completed. Until then, practice_system.accept hasn’t run and the engagement stays in intake.
Why Python here: Firm intake and workflow automation is often scripted in Python, and the async context manager keeps the client lifecycle tidy in a job.
When the firm’s rules change
Changing the rule
Changing the fee dependence threshold can run in Shadow against real intake first. Your change-control setting decides how many approvers it needs, and an engineer’s production change always goes to an administrator or compliance officer.
For your build
For your business owner
The professional services page explains what the agent can take on and how its decisions are defended.
Read the professional services business caseDocs
Install veriproof-sdk, configure the key, and look up industry values for Professional Services.
Try the audit conflict
Run the audit engagement in the simulator and see acceptance stop on the non-audit services flag.