InNumber core architecture
The Invariant Loop
Inspired by the Nataraja Loop
A deterministic world model with advisory intelligence: AI that is free to help, but always inside the boundaries of your domain, your data and your rules.
Our core IP
Why the Invariant Loop is the heart of InNumber
Every InNumber product — InPublish for publishing operations and the reconciliation engine for finance — runs on the Invariant Loop. The general ideas behind it (feedback loops, invariants, human review) are well known. What we own is how they are put together for real industries:
Domain invariants
The rules each industry must never break — milestone order, printer-date limits, one-to-one matches, complete exception lists — written from years of hands-on process experience.
Industry ontologies
How titles, milestones, vendors, ledger lines and bank lines relate to one another, set up once per client and kept in their own space.
Evidence model
Every proposal carries its source rows and every approval keeps the reviewer's reasoning, so any result can be traced back.
Advisory AI gate
AI may suggest and explain, but its output is checked against real records and the invariants before a person decides.
“Invariant Loop” is the name InNumber uses for this architecture. It is not a registered trademark, and the underlying computer-science ideas are not claimed as our invention.
Engineering specification
What “invariant” means here
In computer science, an invariant is a condition that must stay true whatever the system does — before every step and after it. Databases, payment systems and safety-critical software are built around them. The Invariant Loop applies the same idea to AI: the AI may suggest anything, but a suggestion that would break an invariant is rejected before a person ever sees it as an option.
Nataraja is the name of the inspiration; the Invariant Loop is the name of the engineering. Both describe the same system.
Design invariants
- PublishingA milestone cannot be marked complete before the milestones it depends on.
- PublishingA projected printer date is never earlier than today plus the remaining agreed turnaround times.
- PublishingBook cost is the same output for the same inputs: GSM, sheet size, print run and the publisher's own rate card.
- AccountingEach bank or ledger line can belong to at most one approved match.
- AccountingWhen more than one candidate qualifies equally, nothing is matched automatically; it goes to a reviewer.
- AccountingEvery line ends up either matched or listed as an exception — nothing silently drops out.
- GovernanceAI output that cites a column, row or record that does not exist is rejected.
- GovernanceNothing is saved, sent or signed off without a named person approving it.
These are the rules we design and test the engines against. Where a tool is still a demo or prototype, it follows the same rules on sample data; they become client guarantees only in agreed, live deployments.
The inspiration
At the Chidambaram temple, Nataraja — Shiva as the cosmic dancer — performs the dance of creation, preservation and dissolution within a ring of fire that marks the bounds of the cosmos. Our founder, Arun Kumar Vasu, drew a parallel between this theological picture of an ordered, bounded universe and the problem enterprise software faces with AI: how to let intelligence move freely while keeping it inside the rules that matter.
He is not the first to see a bridge between the dance and modern thought. In 2004 a statue of Nataraja was presented to CERN, the European particle physics laboratory near Geneva, by the Government of India. Its plaque quotes the physicist Fritjof Capra, author of The Tao of Physics (1975), who described the cosmic dance as a metaphor for the continual creation and destruction of particles studied in physics.
Working from that parallel, the founder found that the image maps onto a practical six-layer architecture and a four-step feedback loop — a structure with real potential to address a long-standing enterprise software problem: making AI useful without letting it act outside the evidence and rules of the business.
Analogy, not proof
The Nataraja image and Capra's interpretation are cultural and philosophical parallels. They are not a physical mechanism or scientific evidence for how our software works. The architecture below stands on its own engineering: deterministic rules, strict validation and human review — principles that can be tested and measured.
The parallel, side by side
| In the cosmic dance | In our AI systems |
|---|---|
| The dance happens within the ring of fire (prabhamandala) — the bounded cosmos. | AI works only inside the client's domain: their data, their rules, their task. |
| Creation, preservation and dissolution follow an ordered rhythm. | Records move through defined states — proposed, reviewed, approved, archived — never at random. |
| The dwarf of ignorance (Apasmara) is held underfoot. | Unsupported or invented output is rejected before anyone acts on it. |
| The raised hand (abhaya) offers assurance. | A named person approves anything consequential, and the evidence is kept. |
| The cycle continues: each movement leads to the next. | Observe → Understand → Act → Learn: approved outcomes inform the next cycle. |
Six bounded layers
Each layer narrows what the next one is allowed to do. By the time AI reasons, it can only work with validated data, declared relationships and fixed rules.
- Layer 1Data
Bounded input domain
Only the client's own files and records needed for the task in hand.
- Guardrail:
- Task-scoped inputs; no cross-client data; file size and row limits.
- Example:
- A publisher's tracker spreadsheet, or a bank and ledger export.
- Layer 2Representations
Typed schema validation
Every row is parsed by fixed rules into a known shape.
- Guardrail:
- Strict parsers reject unknown or malformed values instead of guessing.
- Example:
- A date column becomes a printer date only if it parses as a real date.
- Layer 3Knowledge graph
Declared dependency graph (DAG)
Entities are linked by explicit relationships.
- Guardrail:
- Dependencies are declared, not inferred by a language model.
- Example:
- A proof round depends on a vendor; its delay moves the printer date.
- Layer 4Memory
Scoped evidence record
Reviewer-approved decisions are kept as evidence.
- Guardrail:
- Scoped to one client; each decision keeps its source records and rationale.
- Example:
- An approved bank match keeps both original rows and the reviewer's note.
- Layer 5World model
Deterministic state-transition model
Deterministic rules define what is possible in the domain.
- Guardrail:
- Turnaround times, tolerances and costs are calculated, never generated.
- Example:
- Book cost from GSM, sheet size, print run and the publisher's own rate card.
- Layer 6Reasoning & action
Constrained proposal with human gate
AI may propose and explain within those rules.
- Guardrail:
- Proposals must cite real columns, rows or records; a person approves.
- Example:
- AI suggests which spreadsheet column is the printer date; the publisher confirms.
Observe → Understand → Act → Learn
- 1Observe
Read only the evidence in scope for this client and task.
- 2Understand
Check it against the domain's deterministic rules and dependencies.
- 3Act
Propose a next step — a match, a mapping, a follow-up — for a person to approve.
- 4Learn
Keep the approved outcome and its evidence for that client's next cycle.
Grounded in established engineering
The loop belongs to a well-tested family of feedback and control ideas. What we add is domain knowledge and strict evidence rules for publishing and accounting.
OODA loop
John Boyd, military strategy
Observe–Orient–Decide–Act; our loop adds an explicit human approval and evidence step.
Cybernetics
Norbert Wiener, 1948
Feedback control keeps a system within bounds — the same principle our rules enforce.
PDCA cycle
Shewhart and Deming, quality management
Plan–Do–Check–Act; continuous improvement from verified outcomes.
Human-in-the-loop AI
Current AI governance practice
Consequential actions require human review, as in the NIST AI Risk Management Framework.
Our promises to clients
- Costs, dates and matches are calculated by fixed rules, not guessed by AI.
- AI suggestions must point to real columns, rows or records; anything else is rejected.
- Nothing is saved, sent or signed off without a person approving it.
- Each client's data stays in their own space and is not used to train for other clients.
- Every approved decision keeps its source evidence and the reviewer's reasoning.
- Clients can export their data and leave at any time.
These limits reduce the risk of AI making things up; they do not remove it entirely, which is why human review stays in the loop. We will claim security certifications only once they are formally achieved.