Skip to main content
An activity is the equation unit of a domain. Writing an activity means three things: giving it a title and description, writing its equation, and marking which of the variables it touches it is allowed to solve for. This page covers the activity as a unit; for the expression syntax itself — literals, operators, functions, units — see Writing equations.

​
What an activity has

  • A title and description — human-readable labels that state what the activity computes.
  • An equation — the mathematical relationship among its variables, written in TrueMath’s expression syntax.
  • Calculable variables — for each variable the equation references, whether this activity may solve for it (see below).
  • A state — active, disabled, or deleted (see Activity state).
An activity’s title and description document what the activity computes, for the people reading a domain.

​
Variables come from the equation

You do not create variables separately and then wire them into an activity. A variable first comes into being when you reference it by name in an equation. Writing
introduces payment, loan_amount, rate, and term into the domain. Once a variable exists, you configure its display, default, and unit on the Defining variables. Reusing the same name in another activity refers to the same variable — this is how activities connect.

​
Calculable variables

An activity is not locked to a single input-output direction. The same equation that solves for a monthly payment from a loan amount, rate, and term can, given a target payment, solve for the loan amount instead. You control this by marking which of an activity’s variables are calculable — the ones it is allowed to solve for. Within that set, which variable an activity actually computes on a given run depends on the values provided and the variable asked for. Marking more variables calculable lets a domain answer more questions from the same activity; marking a variable as not calculable means the activity will only ever read it as an input, never produce it. Mark a variable calculable when it is meaningful to solve for it from the others. In a payment relationship, payment, loan amount, and term are all reasonable to solve for; a variable that should always be supplied — never derived — by this equation is left non-calculable.
A test for what to mark calculable. Go variable by variable and ask: if I knew all the others, would a user naturally want to solve for this one? If yes, mark it calculable. If the math allows it but no one would ask it that way, leave it non-calculable and give that variable its own activity.For an equation relating payment, loan amount, rate, and term, the answer is yes for all four — each is a question a user might bring. But you would not back-solve Private Mortgage Insurance (PMI) from an escrow payment: PMI is naturally derived from loan amount and home price, so it belongs in its own activity rather than marked calculable on the escrow equation — even though the algebra would permit it.

​
How activities compose

A domain is many activities connected through the variables they share. An activity that produces loan_amount and another that consumes loan_amount are linked by that shared variable, without any explicit wiring beyond the common name. Because of this, consistent variable naming is what holds a domain together — reuse the exact key across every activity that refers to the same quantity.
These three activities form a small mortgage domain: loan_amount flows from the first into the second, and payment from the second into the third. Depending on what you supply and ask for, and depending on which variables in which activities are marked calculable, the domain can solve forward to a payment or backward to an affordable home price.
Break a problem into several small activities rather than one large equation. Model each real-world relationship as its own activity and let them connect through shared variables. More focused activities give a domain more ways to reach an answer — it can solve from whatever combination of values a caller happens to have — where one fused equation locks you into fewer directions. Smaller activities are also easier to reason about and to reverse. A useful signal for where to split: nested parentheses in an equation usually mark a seam — if the inner result has its own meaning, something a caller might ask for directly or another activity might consume, give it its own activity. Let TrueMath do the work.

​
Activity state

An activity is in one of three states:
  • Active — part of the domain and used when running calculations.
  • Disabled — kept in the domain definition but not used in calculations. Use it to set an activity aside without losing it, or to stage one that is not ready.
  • Deleted — removed from the domain.
Disabling is reversible and non-destructive; deleting removes the activity upon publishing the domain. GET /v1/domains/:id/activities reports the state of a live activity as published or disabled; deleted activities are not returned. See Domains.
Equations are validated as part of authoring, and incompatible operations — combining values whose dimensions do not match, for example — are rejected rather than silently coerced. See Combining types.