Compliance Guardian (`@onoots/core`)

This is the proof that Supply reuses Onoots OS services rather than copying them. Every Supply engine — spend approval, three-way match, vendor KYS — runs the same Compliance Guardian core that Proptech uses: @onoots/core.

The adapter

lib/guardian.ts is a thin adapter. Each domain maps its outcome onto the two inputs the core needs — an autonomy level and a list of compliance flags — and the core returns the canonical verdict.


import { guardSupply } from './guardian'
 
const verdict = guardSupply({
  level: 'full_auto',                 // AutonomyLevel
  legallyRestricted: false,           // hard-gated act? (audit transparency)
  flags: [                            // SupplyFlag[]
    { rule_id: 'tolerance_breach', severity: 'warning', description: '…' },
  ],
})
// verdict.decision → 'allow' | 'prepare' | 'escalate' | 'block'

The four verdicts

Decision	Meaning
`allow`	Proceed automatically
`prepare`	AI prepares; a human approves (hold / dual approval)
`escalate`	Send up a level (e.g. licensed / CFO)
`block`	Hard stop (fail-closed)

The autonomy ladder

Engines map their resolved route onto these levels:

full_auto — clean, in-band cases.
ai_prepare_human_approve — manager / director gates.
human_licensed_only — CFO, blocked routes, pending KYS, sub-threshold ratings.

A block-severity flag (sanctions, failed KYS) forces a block decision no matter the level. A warning flag downgrades an otherwise-allow case to a human gate.

Why it matters: each vertical reuses ~70% of the OS core. The Guardian is the clearest example — Supply’s verdicts are computed by the very same decide() function Proptech relies on, so compliance behavior is consistent across the OS.

Deploy note

@onoots/core lives in onoots-app (packages/core), linked via a file: dependency in local dev. To deploy Supply (separate repo) on Vercel, publish the package to GitHub Packages or consolidate the repos into one monorepo.

Compliance Guardian (@onoots/core)