METHODOLOGY
The engineering discipline behind every claim on this site.
Four-layer agentic architecture. Six load-bearing operational mandates. 44 codified lessons. The system isn't a demo — it's an audit-first platform we ship into our own production every day.
If you're a CTO, head of engineering, or compliance officer evaluating ONSET — this is the page that should reassure you. Everything else on the site is marketing. This is the spine.
FOUR-LAYER AGENTIC ARCHITECTURE
Four layers. Each owns one concern. Failures are bounded.
The architecture is canonical in onset-platform-spec-v8.md Section 3. Every module ships against this contract or it doesn't ship.
01
Per-module AI Employees
Each AI Employee (Module A through ISO) owns one job and one job only. They share a contract — same telemetry, same audit hooks, same error handler — but they don't share state directly. Failures are bounded to one module.
02
Cross-module orchestration
When Module W wants Module A to apologise to a slow-payer it just hassled, it doesn't reach into A's state — it calls A through the dispatcher with a typed event. flow_rules table is the canonical wiring; every cross-module call goes through it.
03
ONSET Flows
Client-configurable trigger chains. "When a new lead comes through Module A, run intake.qualify; if qualified, hand to Mothership; once Mothership generates a proposal, run a margin check before the Telegram approval gate." All configurable, all audited.
04
Council — Layer 4 meta-agent
Goal-directed coordinator. Say "onboard client X" and Council plans the steps, delegates each module as a tool, self-corrects when a step fails, and reports back when finished. The only autonomous agent on the platform — and even it cannot ship outbound without clearing the approval gate.
SIX OPERATIONAL MANDATES
Constraints, not aspirations. Each one load-bearing.
Humans decide. Machines execute only what was approved.
Every outbound, financial, public or destructive action passes through the 30-second Telegram cancel window. No autonomous-send mode exists in the codebase. This isn't a configurable flag — it's a load-bearing architectural constraint.
60% margin floor.
Any pricing trajectory below 60% blended margin fires an alarm on our internal cost dashboard. We'd rather charge a defensible RM 1,499 than promise RM 999 we can't sustain. Honest pricing is the foundation, not an after-thought.
Hash-chained audit.
SHA-256 chain over every audit-log row. Any tampering breaks the chain visibly via a deterministic verification view. Per-tenant advisory locks prevent concurrent-write races. 7-year retention default.
Zero bug tolerance.
When a production bug surfaces: stop, diagnose, real fix, verify, write the lesson into our internal log, audit other modules for the same pattern, then resume. Process is the moat.
No MVP, no scaffold.
Every page, every workflow, every table ships only when it survives user + admin E2E test on real data. UI without working backend gets deleted, not "completed." If a feature isn't real, it isn't shipped.
Correctness over speed.
A 6-hour session that fixes the root cause beats a 1-hour session that ships a workaround. We don't offer time-vs-correctness choices to ourselves; correctness wins by default.
RELEASE DISCIPLINE
Six gates between “works on my machine” and your tenant.
01
Pre-commit hook blocks leaked secrets
Any literal API key / token / .env stage is rejected pre-push
02
Definition of Done per module
13 mechanical checks per module · evidence required
03
Cross-tenant RLS smoke test before flip
0 rows leaked across tenant boundaries
04
Hash-chained audit verified on every release
Tamper-check view returns 0 broken rows
05
Cost telemetry on every LLM call
Per-call cost logged · enforces the 60% margin floor
06
Lessons file appended on every bug
Each entry: bug pattern + fix + the audit step that catches recurrence
BEFORE YOU MESSAGE
The four questions CTOs ask first.
Why publish your methodology?
Two reasons. (1) It pre-empts the "how do you actually build this?" question that comes up in every enterprise evaluation. (2) It self-imposes a constraint — if we publicly commit to the 60% margin floor, we can't quietly drop it later. The discipline is the product.Where do these principles come from?
They're in our platform master directive — an internal doc that every engineering session reads at start. Owner-set, owner-maintained, version-stamped. The published version is on this page; the full internal directive is not public.Can I see the lessons log?
Sanitised excerpts on request. Each entry documents a bug pattern + the fix + the audit step that catches future recurrence. We share the relevant ones in technical deep-dive calls.Do you have a runbook for incidents?
Yes. An error handler auto-classifies workflow failures against a pattern catalogue (22 patterns to date), auto-applies safe repairs (4 patterns whitelisted for auto-fix), and alerts our on-call channel for everything else. Mean-time-to-acknowledge: < 4 minutes.
Want a technical deep-dive call?
45 minutes with Reginald + your CTO. We walk the architecture, the audit log, the cost dashboard, and answer anything else that comes up. NDA available before the call if you need it.
- NDA on request
- Architecture walk-through
- Live audit log demo
- Cost dashboard tour