BPMB Finance Procurement Routing Prototype

This workspace turns the Finance chapter of the BPMB AA Policy into a small routing engine so an application can answer questions like:

• What is the business-case approval path for this amount?
• Does an IT purchase need GMITC, BITC, GMTC, GCDTO, or Board involvement?
• If the request is a waiver or single-source award, who needs to recommend, endorse, or approve it?
• Who signs the contract, PO, LOU, or LOI?

Product planning details for the configurable admin-driven platform are in docs/prd-aa-routing-platform.md.

Scope

Current scope is intentionally narrow and practical:

• Source: /Users/skyjuice/Downloads/BPMB AA Policy Matrix - Final 030326.pdf
• Policy version: 5.0
• Effective date: 29 January 2026
• Extracted area: Finance chapter procurement flow, mainly CH7-14 to CH7-30

The model currently focuses on:

• Budget / plan routing relevant to procurement
• Approval to Spend / Business Case
• Procurement Strategy
• Procurement Award
• Waiver / Single Source Award
• Panel setup and panel catalogue purchase
• Payment execution
• Signatory routing

Frontend App

The actual application scaffold now lives in /Users/skyjuice/00-Projects/AAAgent/apps/web and is built with:

• Next.js App Router
• pnpm dlx shadcn@latest init --preset b4gO2Tntp
• PocketBase-ready config and schema blueprint
• Protected sign-in for approved internal users only

Run the app with:

pnpm dev:web
pnpm lint:web
pnpm build:web

PocketBase blueprint assets are in /Users/skyjuice/00-Projects/AAAgent/pocketbase.

Authentication

The web app now requires sign-in before users can open the overview, route checker, policy evidence, or admin area.

Environment variables for /Users/skyjuice/00-Projects/AAAgent/apps/web/.env.example:

• NEXT_PUBLIC_POCKETBASE_URL: PocketBase base URL
• POCKETBASE_AUTH_COLLECTION: auth collection name to use for login, for example users
• AUTH_SECRET: secret used to sign the app session cookie
• AUTH_ALLOWED_EMAILS: optional comma-separated allowlist for who can sign in
• AUTH_ALLOWED_EMAIL_DOMAINS: allowed work-email domains, default bpmb.com.my
• AUTH_ADMIN_EMAILS: optional comma-separated allowlist for who can access /admin
• AUTH_COOKIE_SECURE: auto, true, or false for environments that terminate TLS differently
• AUTH_SESSION_HOURS: session lifetime in hours

Recommended PocketBase setup for self-hosting:

• create or use an auth collection for internal users
• disable public self-registration on that collection
• create users manually or through your internal provisioning process
• keep AUTH_ALLOWED_EMAIL_DOMAINS=bpmb.com.my so only BPMB work accounts can sign in
• use AUTH_ALLOWED_EMAILS only if you want to narrow access further to specific users
• set AUTH_ADMIN_EMAILS for the people who should manage route logic

Run

npm test
npm run route -- examples/it-project-over-500k.json
npm run route -- examples/non-it-waiver-350k.json
npm run route -- --json '{"amount":600000,"budgetStatus":"approved","procurementPath":"standard_award","documentType":"contract_like","isItRelated":true,"isByOtherFunction":true}'

Use --format json if you want machine-readable output for an API prototype.

Input Model

The route builder accepts:

• amount: numeric amount in RM
• budgetStatus: approved, annual_plan, contingency, or unbudgeted
• procurementPath: standard_award, waiver, panel_setup, or panel_catalogue
• documentType: contract_like, po_like, or none
• isItRelated: true or false
• isByOtherFunction: true or false
• isShariahRelated: true or false

Important Caveats

• This is a routing-engine foundation, not a substitute for the policy PDF.
• A few lower-threshold rows were heavily wrapped in the PDF extraction, so those rules are marked with lower confidence in the output.
• [Approve] is treated as an alternate approver and Approve* is preserved as-is because the policy note on non-conflicting approvals applies to those rows.
• Before using this in production, the low-confidence rows should be visually validated against the original PDF and then locked into a reviewed rules dataset.