01The shape
Every persona's structured output becomes a row in approvals — title, body, payload, impact (sensitivity / affects / reversible), the team_member it came from, the requester, the timestamps. That's the entire surface area.
When the Engagement Manager orchestrates a multi-consultant request, she dispatches consultants in parallel and produces one synthesised parent approval with each consultant's contribution as a child row pointing at the parent via parent_approval_id. The reviewer sees one row to approve; expanding it surfaces the per-consultant contributions verbatim.
02The card
Here's what a parent approval looks like when Sara has dispatched three consultants on a vendor-add request and synthesised their views:
ACME Shanghai vendor add: counter-propose two-gate onboarding; Wednesday PO not feasible
Team recommendation: decline the Wednesday landing date and counter-propose a 5+5 two-gate onboarding. Both consultants flag this as partner-authority — the customer's CFO must accept the slip or sign a written risk-acceptance for releasing without the controls below. I am not recommending the latter.
Material-loss exposure — the supplied name 'ACME Shanghai' is generic and matches multiple Shanghai entities on OFAC / EU / UK lists. Need the registered Chinese legal name + UBO + clean OFAC / EU / UK / consolidated sanctions screening on both before vendor-master entry.
Wednesday fails on physics, not on D365. China→destination ocean FCL is 38–45 days door-to-door under FOB Shanghai; air freight collapses transit but inflates landed cost 6–10× and still needs 2-3 days clearance each side, plus 10-25 days vendor production on a new program.
Default GL: 60140 (Asia-imported raw materials). 60140 isolates the China-imported flow from the EU domestic flow at COA level — needed for the customs-position cross-tab in the next quarterly close. Considered 60100 (general raw materials) and rejected because it would mix flows.
The parent shows the team's verdict; the children show the team's reasoning. One approval click, one decision recorded.
03The decision
The reviewer chooses approve / reject / cancel. The choice is persisted via decide_approval, a SECURITY DEFINER RPC — so the table is not directly writable from the app, only via the gated path. The decision is idempotent (the second click on the same approval is a no-op, not a duplicate).
On approval, an AFTER UPDATE trigger materialises the decision into the knowledge graph: a row in knowledge_entries with kind='decision', the approval body as context, and a back-reference to the source approval. Now every persona that runs next on this project sees the decision in their grounding context — the team starts compounding.
On rejection, the decision is logged with the reviewer's note, but the knowledge graph is untouched. The proposing consultant doesn't learn from a rejection automatically — that's a future iteration, not the current shape.
04The queue
The approval queue is tenant-scoped via Postgres row-level security. A reviewer sees only the approvals for the company they have a membership in. Filters by state (pending / approved / rejected / cancelled), by project, by persona. Counts surface inline so the operator can triage at a glance.
Children of a synthesised parent are filtered out of the queue list view (only the parent shows; expanding it surfaces the contributions). Operationally one human review, one decision; in the database, the audit lineage is intact.
05What gets logged
Every approval lifecycle event — pending insert, decision, soft-delete — is captured by a generic activity_log trigger that runs on every tenant-scoped table. The reviewer's identity, the timestamp, the before / after state, and the optional decision note are all there. Immutable by design — see Audit trail for the deeper story.
Most platforms put the human at the start of the loop ("review the agent's output before pressing send"). nuya puts the human at the decision gate: the consultants do the analysis, the queue captures the decision, and the audit trail proves it.