Documentation
Architecture notes presented like a product surface, not a raw Markdown dump.
This reference is sourced from the public design document and framed for founders, designers, and engineers who need the rationale behind INFOC ONE.
INFOC ONE: Design Thinking & Architecture
design.infoc.one | Public | June 2026
What this is: How we think about building INFOC ONE. The principles, frameworks, and decisions that shape every product and engineering choice we make. Written for developers, designers, and technical founders who want to understand the platform deeply.
What this is not: A marketing document. A competitor analysis. A feature list. Everything here is about how and why, not what and how much.
Table of Contents
- The Problem We Are Solving
- Design Principles
- Platform Architecture
- The ONE Naming System
- ONE Access: Access Control Philosophy
- ONE Prism: Design System
- Extensibility
- ONE AI: Intelligence Architecture
- Deployment Philosophy
- Singapore First
- What We Will Never Do
- Changelog
1. The Problem
Singapore SMEs run their business on 3 to 5 disconnected tools. Invoicing in one app. Payroll in another. Inventory in a spreadsheet. Customer orders in a messaging app. At month-end, a finance manager spends two days reconciling them all by hand.
This is not a technology problem. The tools exist. The problem is fragmentation. Each tool is optimised for one task and blind to the others. Stock and finance do not talk. Sales and payroll do not connect. Every integration is a project. Every month-end is a crisis.
INFOC ONE solves this with a single system for the whole business: finance, payroll, sales, stock, POS, projects, and planning, all connected from day one.
The one sentence: Your business is fragmented. ONE fixes it.
2. Design Principles
These principles govern every decision, from architecture to UX to naming. Each one exists to make a specific failure mode structurally impossible, not merely discouraged.
Principle 1: Singapore first, not Singapore adapted
Software built elsewhere and modified for Singapore is not the same as software designed for Singapore from the start. CPF is not a compliance checkbox. InvoiceNow is not a third-party connector. PayNow is not a payment option. They are first-class features built into the core data model.
When CPF rates change, INFOC ONE updates. When InvoiceNow specifications change, INFOC ONE updates. The customer does not manage compliance; we do.
Principle 2: Statutory values are data, never code
CPF ceilings, the GST rate, and EP and S-Pass thresholds change on government timelines. A rate hard-coded into a program is a latent bug with a known future trigger date. So every government-set value lives in effective-dated data, verified by two people, with a source and a review-due date. The application reads it; it never embeds it.
Principle 3: Simple on the surface, rigorous underneath
A Singapore SME owner should be able to assign access to a team member in 30 seconds. The complexity underneath (policy evaluation, tenant scoping, field masking) is invisible. The admin sees one dropdown. The engine enforces several layers of isolation.
This is the design contract: make hard things look easy without hiding what makes them hard. The documentation exposes the full depth. The product surface shows only what the user needs at that moment.
Principle 4: The 10-second rule
Every screen must be evaluatable by a first-time user in 10 seconds. What is this screen? What is the one thing I should do? What happens if I do it? If a screen cannot answer all three questions in 10 seconds without reading documentation, it is redesigned before shipping. The same test applies to a developer reading an API endpoint.
Principle 5: One writer, one truth
For any capability that matters (posting to the ledger, issuing a document number, enforcing access), exactly one piece of the system is allowed to do it. Two code paths that can both write the same thing eventually drift, and a drifted financial system is an un-auditable one. Funnel everything through a single writer and the rules are proven once and enforced everywhere.
Principle 6: AI proposes; humans approve
No AI agent can post a journal, approve a payroll run, or submit a statutory file on its own. The agent does its work, proposes an action, and stops. A human reviews and approves. Separation of duties is not a setting; it is built into the system so that the same agent can never both propose and approve the same action.
Principle 7: Data is permanent. Behaviour is temporary.
When a subscription ends, data is retained before any deletion. When a status transition is reversed, the record of the original transition remains. Posted financial entries are never edited; corrections happen by reversal, leaving the full history intact. Data permanence is a trust contract, and businesses depend on their historical records.
3. Platform Architecture
3.1 A modular monolith, not microservices
INFOC ONE is delivered as a single deployable engine with strict internal module boundaries, one module per business domain.
A 10-to-100-employee SME tenant does not generate the transaction volume that justifies the network, deployment, and observability cost of many independent services. More importantly, financial correctness wants in-process transactions that span modules: an invoice posts the receivable and the general ledger and the GST in a single database transaction. Across separate services that becomes a distributed saga, with more failure modes, not fewer.
Module boundaries give the organisational benefits of microservices (clear ownership, independent reasoning) without the operational cost. Modules talk to each other through a shared domain layer, never by reaching into each other's tables. If a module ever truly needs to scale out on its own, the seam is already there.
3.2 Events through a transactional outbox, not a broker
Background work such as notifications, AI proposals, analytics projections, and document jobs flows through a transactional outbox drained into a background job queue. There is no separate message broker.
The reason is correctness. The outbox row is written inside the same database transaction as the business change it describes. That is the only way to guarantee an event fires if and only if the data committed. A broker published outside the transaction can fire on a rolled-back write, or silently drop one that committed. The job queue then provides retries, backoff, and scheduling at SME scale, with a small open-source footprint, and without the partitioning machinery of a system built for a problem this workload does not have.
3.3 ONEKernel: a contract with two faces
Every part of the platform depends on a single cross-cutting contract called ONEKernel. It has two complementary faces:
- a frozen runtime face: compiled, structural types and shapes (status models, identity, the posting engine, lifecycle state machines);
- an evolving governance face: a reviewable manifest of rules that generates artifacts and captures the why behind each contract.
The two faces exist to kill one specific class of bug: a value baked into code that silently diverges from the law and from the documentation that is supposed to describe it. A build-time check fails the build if runtime code and its governing rule ever disagree, if a statutory value appears in runtime code, or if a contract exists with no governing rule. The contract evolves additively: new optional shapes can be added, and existing ones are never removed or renamed without a major version and a published migration guide.
3.4 Stable identity, decoupled from names
Three separate mechanisms handle three genuinely different problems that a single "document" interface used to conflate:
- Instance identity. Every record carries an immutable, time-ordered resource name the moment it is created. Physical names, routes, and file paths can change freely; the identity of a specific record never does.
- Kind identity. Every kind of thing in the system has a stable code, so the system can rename a screen or a route without ever losing track of what it refers to. The registry is the source of truth; code references it, never the reverse.
- Field shape. Every column conforms to one of a fixed catalogue of typed shapes. This is what makes "money is a fixed-scale decimal, never a float" a property of the whole system rather than a per-table convention.
3.5 Tenant isolation is physical
Each tenant is a physically separate database. A second isolation layer inside the database backs it up. The primary isolation is the separate database; the second layer means that even a bug that connects to the right database with the wrong tenant context still cannot read or write across the boundary. For a financial system, this redundancy is cheap insurance against the single most reputationally fatal failure, a cross-tenant leak, and it makes clean tenant offboarding a single, complete operation.
3.6 Posting integrity
One engine, and only one, is allowed to write general-ledger entries. It runs an atomic posting sequence: validation, compliance lookup, audit, numbering, and the write all succeed together or roll back together. Idempotency keys make a retried post safe. Because the downstream event is written in the same transaction, it is delivered exactly once on commit. The ledger invariants (debits equal credits, posted rows are immutable, statutory sequences are gapless) are proven once, here, instead of re-proven in every code path that might otherwise touch the ledger.
3.7 AI provenance in the data model, not the UI
Every consequential action records who or what initiated it, whether a human reviewed it, and a reference back to the full reasoning chain. This is structural data, not a badge on a screen. When an auditor asks "did an AI create this payroll run, and was a human in the loop?", the answer is in the database, not in a log file. AI provenance is a first-class data concern.
4. The ONE Naming System
4.1 The rule
Every framework, package, and product starts with "ONE", followed by one word that describes the function in plain English, with no acronyms and no jargon. A developer reads the name and knows the purpose before opening documentation. That is the test.
4.2 The principal components
A few of the names you meet first. Read the name, know the purpose:
| Name | What it is |
|---|---|
| ONEKernel | The shared contract everything depends on |
| ONE Atelier | The web application surface |
| ONE Compass | The mobile application surface |
| ONE Prism | The design system (tokens and components) |
4.3 The business applications
ONE ERP ONE HRM ONE CRM ONE POS ONE WMS ONE EPM ONE PSA ONE AI
Eight applications, one shell. A user who learns ERP already knows how to navigate HRM: the navigation contract is identical and only the accent colour changes between apps. "Ask ONE AI" is reachable from every screen as an overlay, never a tab, so it never consumes layout.
5. ONE Access
5.1 The problem with access control in business software
Most business software gives administrators a table of permission checkboxes. There are hundreds. The administrator does not know which to check, so they either grant everyone everything (insecure) or hire a consultant (expensive).
ONE Access is built around a different question: what does a business owner actually need to do? Give the finance manager access to invoices. Give the HR manager access to payroll. They should not need to understand policy languages or token claims.
5.2 Layers: one visible, the rest invisible
ONE Access enforces several layers, and only one is visible to the administrator.
- Authentication (ONE Gate). A user has a valid session or they do not. Authentication runs in-process, with no separate identity server to operate at SME scale.
- Module (visible). The administrator assigns a role per person per module. One dropdown. The module either appears in the sidebar or it does not.
- Action (invisible). A uniform permission model decides whether a role may perform an action, and the system denies silently: if you cannot perform an action, the button is simply not there.
- Record (invisible). Physical per-tenant isolation, backed by a second isolation layer, means a user cannot reach another company's records regardless of what they type into a URL.
- Field (invisible). Sensitive fields are masked by role before data reaches any surface. An HR staff member sees a masked salary that a finance manager sees in full. Because masking happens below the surface, it applies everywhere: web, mobile, API, and exports alike.
5.3 Why this design
The complexity is in the engine, invisible to the administrator. Business owners are experts in their business; they should not have to become experts in access-control systems to use their software. And because every consumer (web, mobile, and AI) reaches data through the same domain layer, the same gates apply to all of them. A rule placed only in the web UI would be invisible to the mobile app and to AI.
6. ONE Prism
6.1 Why a design system, not just a component library
A component library gives you buttons and tables. A design system gives you a visual language (tokens for colour, spacing, motion, and radius) so every surface feels like one product. Every surface in ONE Prism draws from shared design tokens, and no raw hex value lives in a component.
6.2 One shell, eight accents
Every application renders inside the same three-layer navigation contract. Each app carries its own accent colour so muscle memory transfers between them, while everything else in the shell stays identical.
6.3 Singapore components
Standard libraries are built for global markets. ONE Prism includes Singapore-specific building blocks no standard library provides:
- SGD currency handling: thousands separators, two decimals, and correctly placed negative signs. Internally money is a fixed-scale decimal; floating point is never acceptable for financial data.
- UEN validation: Singapore UEN format checked on entry, so a malformed UEN never reaches a submitted invoice.
- CPF-aware displays: contribution rates driven by data rather than hard-coded constants.
- PayNow QR generation: built into invoicing, generated from UEN and amount.
7. Extensibility
7.1 Every business is different
A wholesale distributor needs a field for supplier lead time. A consulting firm needs project codes on invoices. These are not core features. They are customisations that belong to specific businesses, and the platform is built so they can be added without modifying its core.
7.2 How the platform stays extensible
- Typed fields. Custom data conforms to the same typed-shape catalogue as everything else. A field cannot be invented at runtime; it is declared and checked before it ships.
- Stable identity. Because every kind of thing has an identity decoupled from its name, a customisation built against a screen or entity keeps working even as names and routes evolve.
- One integration surface. External integrations, the mobile app, and AI all reach the platform through the same domain layer, over the same gates. There is no side door that skips authorization, audit, or data-residency rules.
7.3 Roadmap
A packaged-extension model is a future direction, not a current feature.
8. ONE AI
8.1 What AI-native means
There is a difference between a product that has AI features and a product with an AI-native architecture. AI features are a button that calls a model and shows the result, on top of a data model designed without AI in mind. AI-native means the data model records AI provenance from the start: every consequential action is traceable to a specific reasoning chain, and every status transition records whether a human or an agent initiated it. The AI layer is structural, not cosmetic.
8.2 Two layers, strictly separated
- The infrastructure layer is never user-facing. It routes work to models, orchestrates multi-step reasoning, holds live session state, and keeps a durable record of every interaction.
- The Beacons are the user-facing AI. Six domain-scoped Beacons map cleanly onto the business domains and onto the separation-of-duties model, so each Beacon has a bounded scope and a clear human counterpart.
| Beacon | Watches |
|---|---|
| Finance | Bank lines, supplier-invoice matching, GST, receivables and payables aging, journal anomalies |
| Sales | Lead conversion, quote-to-cash, overdue chases, customer health, win and loss |
| HR | Payroll anomalies, CPF brackets, IR8A correctness, leave balances, headcount |
| Operations | Stock levels, POS reconciliation, goods-receipt flow, demand forecast, reorder points |
| Service | Project burn, timesheet completeness, billing readiness, margin slippage |
| Compliance | IRAS, MOM, ACRA, MAS, and PDPC deadlines, rate changes, and filing windows |
8.3 Human-in-the-loop is architectural
No Beacon can post a journal, approve a payroll run, or submit a statutory file on its own. The agent proposes; a human approves. A Beacon can never appear as the approver of its own proposal; that is enforced in the system, not left to policy. When a Beacon routes a proposal to a particular person for approval, routing is explicitly not approval.
8.4 Personal data never leaves the premises
Salary data, identity numbers, and employee records route to an on-premises model. They never reach an external API. General operations route through a model gateway to a hosted model. The routing rule is enforced centrally, not left to application code, so a developer cannot accidentally send personal data to an external model by calling the wrong function; it is intercepted and routed by data classification.
9. Deployment Philosophy
INFOC ONE runs in a Singapore region, multi-tenant, with each tenant physically isolated. The same engine and the same physical per-tenant isolation are used in development and in production, so what a developer tests locally is the shape that runs in production. Because tenants are physically separate, onboarding and offboarding a tenant are clean, complete operations rather than careful filtered deletes.
Every release carries verification artifacts: automated checks whose results are recorded as evidence. "Done" means a verifiable artifact exists, not that a checklist was ticked. A check that is skipped is recorded as skipped, never as passed.
10. Singapore First
10.1 What this means in practice
Singapore compliance is not a module or an add-on. It is built into the core data model and held as effective-dated data, verified against government-published specifications.
- CPF uses current CPF Board rates across all age brackets, with the Ordinary Wage ceiling held as effective-dated data rather than hard-coded.
- GST is held as an effective-dated value rather than a hard-coded constant, so a rate change is a data edit, not a code change.
- InvoiceNow (Peppol PINT-SG) is a first-class part of the invoicing model, generated from the platform's own invoice structure rather than bolted on, and built to align with the national e-invoicing rollout.
- PayNow QR generation is built into invoicing.
- IR8A is produced in the IRAS Auto-Inclusion Scheme format.
- Identity numbers are encrypted at rest, masked in all responses, exports, and events, and every full view is access-controlled and logged.
10.2 Compliance as data, dated to the document
Every government-set value carries an effective-from date, a source, who verified it, and when it is next due for review. Lookups are dated against the posting date of a document, not "today", so a document posted into a prior period uses the rate that was law then, and a future rate change becomes a data edit with an effective date, never a code deploy. Values that have not been re-verified within set windows raise warnings and, past a threshold, block production. A rate nobody has checked in six months is more dangerous than a missing one, because it looks current.
10.3 PDPA by design
The Personal Data Protection Act governs how INFOC ONE handles personal data, and the compliance is architectural:
- Personal data does not leave Singapore (for cloud customers) without explicit consent.
- Identity, salary, and medical data are encrypted and access-controlled at the data-model level.
- Every access to sensitive data is written to an append-only audit trail.
- Deletes are reversible for the required retention period before any removal.
- A Data Processing Agreement is provided before any personal data is stored.
Statutory record-retention in Singapore and INFOC ONE's own retention policy are tracked separately and never conflated.
11. What We Will Never Do
These commitments are public. Holding us to them is part of the design.
We will never send Singapore employee data to an external AI service without explicit consent. Salary, identity numbers, and medical records route to an on-premises model by default. External routing for sensitive data requires an opt-in at the tenant level, with clear disclosure to the administrator.
We will never introduce a paid-licence or source-restricted tool into the core platform. Every tool in the stack is OSI-approved open source. Licences that restrict commercial reuse are flagged incompatible and rejected.
We will never make a breaking change to the ONEKernel contract without a major version bump and a published migration guide. The contract is the contract. It evolves additively, and existing shapes are never removed or renamed silently.
We will never use floating point for financial amounts. Money is a fixed-scale decimal. Floating-point arithmetic produces rounding errors, and rounding errors in payroll produce incorrect statutory submissions.
We will never hide audit-trail entries. The audit log is append-only and permanent. Status transitions, agent actions, and sensitive-field accesses are logged and cannot be deleted.
We will never let an AI act unilaterally on a consequential financial action. Posting, approving, and closing always require a human, and an agent can never approve its own proposal.
12. Changelog
This document is version-controlled. Every change is tracked with a date, description, and version number.
| Version | Date | What changed |
|---|---|---|
| Current | June 2026 | Architecture overview revised and expanded. |
| 1.0.0 | April 2026 | Initial publication. |
How to contribute
This document evolves as INFOC ONE evolves. Feedback is welcome via the contact page.
INFOC ONE Design Reference, June 2026 Published at design.infoc.one Maintained by the INFOC ONE Platform Engineering team