A Formula Language for Financial Models
A domain-specific language connecting the fields, relationships and calculations of a financial data model.
- The model amount is 1,000; related record A supplies a share of 40%.
- An illustrative formula multiplies those values to produce a result of 400.
- The formula resolves values from separate records through the shared model vocabulary.
What It Does
The formula language lets analysts express calculations, selection rules and scenario adjustments using the vocabulary of a financial model. Formulas can refer to properties, related records and configured values, rather than the storage layout behind them.
A rule can combine a record’s properties with those of its parent, inspect a related collection, or use a configured value. The same model vocabulary supports interactive editing and server-side workflows.
The illustrative formula resolves an amount and a share from separate model records, not from the cells displaying them.
The Design Problem
The model is not a flat spreadsheet. Some values live directly on a record; others belong to related collections or are defined through configuration. A name in a formula might resolve to one value or several. Users need a consistent language across those differences, while each operation needs the right record context.
Formulas also serve different purposes. A selection rule decides whether a record belongs in a collection. An adjustment changes a field. A dependent calculation updates other values after an edit. These operations share a vocabulary without being interchangeable.
Design Decisions
Field resolution
Field descriptors connect a named term to its location, type and relationships in the data model. Resolution can read a direct field, find an entry in a related collection, or return several values. Domain functions handle operations such as checking the status of a related record or its membership in a group.
The parser works with these identifiers and function definitions, rather than embedding the application’s record structure. The calling workflow supplies the model context in which an expression runs.
Names and identifiers
Analysts write with readable names. Stored expressions use consistent identifiers. The editor translates field names without changing quoted values inside an expression.
Parsing produces a structured representation of operators, fields and nested function calls. The editor validates syntax, identifiers and arguments before saving; execution uses the corresponding field resolvers and function implementations.
Formula dependencies
Configured formulas declare their input and output fields. When a field changes, the formula system follows the affected dependencies and applies their calculations to the model. Editing a related collection, for example, can trigger formulas that depend on that collection.
Browser edits and server-side scenario adjustments reuse this mechanism. Selection uses the expression evaluator against a record and its parent. The shared vocabulary connects these workflows while each retains its own execution rules.
Selection queries
Some selection rules identify a limited set of records to fetch before evaluating the full expression. “Record A or B, with an additional condition” permits that restriction; “record A, or anything meeting that condition” does not.
The system uses this shortcut only when the expression’s structure supports it. Other formulas run through the evaluator without narrowing retrieval.