Model your system as nodes, relationships and formulas. Change anything, and every value it touches recomputes — across units, states and time — without you editing another line. Your agents query numbers they can explain, and prove.
An agent reprices a plan, rebalances a portfolio, plans capacity. The number it used came from a spreadsheet that drifted, a query with no units, or a model no one can re-run. Six months later an auditor asks why — and nothing holds up.
AwareDB sits between your agents and your business reality. Every value is computed from an explicit model — unit-correct, reproducible, reversible.
The agent asks in language; AwareDB answers in math.
A closed loop where every decision is grounded in a model you control — not the agent's say-so.
Your agents read what's happening and propose a change to the model.
AwareDB recalculates with correct units, applies your formulas and rules, and returns the result — or runs a what-if first, without touching stored data. You change one input; everything it impacts recomputes on its own — you never touch the rest of the model.
They execute on a number they can explain, with every change logged and reversible.
Language guesses. The model doesn't.
A node carries inputs and formulas about itself — local, plain, written as if nothing else exists. You never declare what depends on it, never enumerate combinations, never wire the consequences. At calculation time the engine resolves the result across every dimension its inputs carry — units, states, time — and recomputes everything your change touches. You author inputs; you read outputs; the impact in between is the engine's job.
runway = cash / (payroll + other − mrr) = 750,000 / (66,667 + 12,000 − 21,278) = 13.1 moWrite a formula once as plain math. If an input it touches has variants, the result comes back per variant. The formula never mentions them.
A value carries kW, EUR, km. The unit is just another dimension that rides through the math; a mismatch surfaces as a warning, never a silent wrong number.
Declare that a value has states in one place; every formula downstream becomes state-aware on its own, resolved on demand.
Change an input and read the new output. A scenario or a projection is the same recompute, run against a copy — nothing downstream to touch, nothing saved.
Same inputs, same outputs, every time. Every change logged with the deltas to undo it.
Model each node as if nothing depends on it. The engine resolves every dimension — variants, levels, time, states — at calculation time.
A car's motor, wheels and battery each come in variants, and you want range, top speed and weight for every combination.
→ Write range = battery.capacity / power_at_speed(speed) once, as if there's one car. Declare the variants separately, where they live. At calculation time the result comes back resolved per configuration, in km — the formula never mentions a variant.
Price a train: a friction pad rolls into a brake system, into a bogie, into a car, into the train, into a 30-year lifecycle cost.
→ Each level's cost is written as the sum of the level below — nothing more. Swap one component and the total recomputes through all five levels, maintenance intervals carried as real distances. You never trace the ripple.
Worked example: train BOM →Know the moment you sign a client whether the team is now overbooked — when hours, rates and headcount usually live in three different places.
→ utilization = hours_needed / capacity_total, overbooked = utilization > 1. Add the client to the model; the answer is already computed. Nothing else to update.
Ask how a hire, a price change or a raise moves runway — and get the full recompute, every target included.
→ Change one input. MRR, burn, runway and every OKR recompute together, against a copy — nothing saved. Ask the next question. The what-if is just the model, asked differently.
Worked example: SaaS P&L →Compute EUR/month and m/s² with the same correctness — euros and kilowatts never silently mixed.
→ Every quantity is unit-aware end to end; a dimensional mismatch surfaces as a warning, not a wrong number. The car and the P&L run on the same engine.
Worked example: any model above →The right choice depends on state — holding period, market, allocation — with too many combinations to try by hand.
→ Describe the constraints and the target once. Goal-seek, optimize and constraint-solve search the model's states and return the input that hits it. You state what good looks like; the engine finds it.
Worked example: portfolio →One command endpoint, sixteen verbs. A typed Python client mirrors it. Query, update, and run analyses from any language.
SDK reference →Runs in your environment; your model, your data. The engine is private — self-hosting is by arrangement, so get in touch.
Talk to us →Call AwareDB over HTTP from the automation tools you already have. Run scenarios and read results inside existing workflows.
Install the Python client, push a few nodes with formulas, and read back a computed, unit-correct value in minutes.