Glossary

One of the two fundamental fact transaction types in the immutable fact stores used by Smart Placement and Smart Underwriting.

Addition transactions create new facts or add additional values to data points, contributing to the append-only log that maintains complete audit trails and historical records.

See also: Retraction, Append-only log.

A system that derives information across sets of policies to enable portfolio-level insights.

The engine calculates portfolio statistics, performance metrics, and custom business calculations in real-time, with data organized and filtered by various criteria such as geography, product type, or risk characteristics.

See also: Portfolio management.

The comprehensive REST API system that handles all communication with Smart Placement and Smart Underwriting.

It includes both public APIs for external integration and internal APIs used by the frontend and development tools, with auto-generated OpenAPI documentation and webhook support for real-time external system updates.

See also: OpenAPI, Webhook system.

A data storage approach where new information is only added to the end of a record, never modifying or deleting existing entries.

In Smart Placement and Smart Underwriting, this creates a permanent, immutable history of all fact transactions, enabling complete audit trails and time-travelling queries to view any contract’s state at any point in its history.

See also: Immutable, Addition, Retraction.

In Brossa, an assessment is a logical evaluation or judgement made about a risk or policy condition.

Assessments are generated through conditional rules and utilise Ternary Logic with outcomes of True, False, or Unknown. They provide the foundation for underwriting decisions and risk evaluation within Smart Placement and Smart Underwriting.

See also: Rules, Ternary logic.

A specific Brossa syntax feature that allows querying historical values of data points at particular moments in time.

For example, at-time (now - 10s) query a retrieves the value of data point a as it existed 10 seconds ago, leveraging the immutable fact store’s complete historical record.

See also: Time-travelling queries.

Complete historical records of all changes made to contracts and their data points.

The immutable fact store in Smart Placement and Smart Underwriting automatically captures every transaction with timestamps and revision information, providing comprehensive tracking for compliance, debugging, and analysis purposes.

See also: Immutable, Append-only log.

A goal-driven reasoning strategy used by Brossa’s tracing evaluator where the system works backwards from a desired outcome to determine what facts are needed.

When you query a data point that hasn’t been computed yet, backward chaining identifies the missing dependencies and shows what information must be collected to fulfill that goal.

See also: Forward chaining, Tracing evaluator.

An advanced type-checking algorithm used by Brossa that can both verify that an expression has a specific type and automatically infer the type of expressions without explicit type annotations.

This enables more flexible and intuitive spec writing while maintaining strong type safety.

See also: Type inference.

Brossa is the domain-specfic language that powers Smart Placement and Smart Underwriting.

It allows insurers to model and automate the placement and underwriting of speciality insurance products through structured, expressive code. Brossa handles the complex, bespoke, and continuously evolving nature of insurance data models that traditional standardisation efforts haven’t addressed.

For further details, refer to TK_update_The Brossa language(explanation/getting-started/the-brossa-language.md).

The out-of-the-box development environment used to write Brossa spec files.

For further information, refer to TK_update_Set up and use Coder(how-to-guides/set-up-and-use-coder.md).

In Brossa, collected data points are those that require manual input of values rather than being computed automatically.

These represent the raw facts that must be gathered from external sources, documents, or user input to fulfil the goals of a spec.

See also: Data points, Derived data points.

A scriptable command-line interface in Smart Placement and Smart Underwriting for complex administrative tasks and ad-hoc queries.

The console enables Solutions Engineers and system administrators to perform batch operations, run bulk analyses, and execute advanced system management tasks efficiently.

See also: REPL.

In Smart Placement and Smart Underwriting, a contract is a Brossa spec coupled with a set of facts.

Contracts represent the complete state of an insurance policy or risk assessment, combining the programmable schema (spec) with the actual data values (facts) that have been collected or computed.

See also: Spec (specification), Facts, Evaluation.

The fundamental building blocks of Brossa specs, representing individual pieces of information within an insurance product or risk assessment.

Data points can be either Collected data points (requiring manual input) or Derived data points (computed automatically from other data points).

For more information, refer to TK_update_Data points(reference/data-points/README.md).

In Brossa, derived data points have values that are computed automatically based on other Data Points within the spec.

These represent calculated fields that update reactively as their dependencies change, similar to formulae in a spreadsheet.

See also: Collected data points.

The predictable and consistent behavior of Brossas evaluation engine, where identical inputs always produce identical outputs.

This ensures that contract evaluations are reliable and reproducible, with no random or unpredictable elements affecting the results.

See also: Pure functional approach.

The automated process of extracting and structuring data from various document formats to populate Smart Placement and Smart Underwriting contracts.

This capability eliminates manual data entry by automatically parsing documents and feeding structured information into the underwriting and evaluation processes.

A programming language designed for a specific domain rather than general-purpose computing.

Brossa is a DSL created specifically for insurance and placement operations, with language constructs tailored for modeling insurance products and risk assessments.

A hierarchical naming convention used to organize data points by separating levels of detail with full stops (dots).

Dot notation helps structure complex data by grouping related elements.

For example, user.name.first clearly indicates that "first" is a subfield of "name," which belongs to "user." This format enhances readability, consistency, and ease of data management, especially in nested or structured data systems.

Goal-driven workflows that automatically adapt based on real-time data and contract states.

These workflows determine the next steps needed to progress submissions or complete processes based on current conditions rather than following fixed sequences.

See also: Goals.

The underlying data storage architecture used in the fact store by Smart Placement and Smart Underwriting.

This extended EAV model provides flexibility for storing diverse insurance data whilst maintaining immutability and full audit trails through an append-only transaction log.

In Smart Placement and Smart Underwriting, evaluation is the process of executing a Brossa spec against current facts to determine the state of a contract.

Evaluation is pure, taking existing facts as inputs and producing new derived facts and assessments as outputs. Contracts are reactive and automatically re-evaluate as new data becomes available.

See also: Contract, Facts, Reactivity, Tracing evaluator.

In Brossa, facts are the actual values assigned to data points within a contract.

Facts represent the concrete data that has been collected or computed, distinguishing them from the spec which defines the structure and rules for how facts should be processed.

See also: Contract, Data points.

A data-driven reasoning strategy used by Brossa’s tracing evaluator, where the system automatically computes new derived facts as soon as their dependencies become available.

This happens automatically when you provide facts to collected data points, triggering the computation of any derived data points that depend on them.

See also: Backward chaining, Tracing evaluator.

In Brossa, every data point functions as a goal that can be fulfilled by providing valid facts.

Simple data points are fulfilled when values are supplied, whilst composite data points are fulfilled when all their subgoals (dependencies) are satisfied. This goal-oriented approach drives workflow progression and automated reasoning.

See also: Backward chaining, Dynamic workflow management.

A data standard from ACORD that provides structured formats for insurance data exchange.

GRLC can be incorporated into Brossa specs where applicable to insurance workflows and data management.

A web technology used by Smart Placement and Smart Underwriting for server-side UI generation that enables dynamic web applications without complex client-side JavaScript frameworks.

htmx allows the policy editor to generate forms on the server while maintaining responsive, interactive user experiences.

For further information, refer to https://htmx.org/

See also: Server-side rendering, Policy editor.

The unchangeable nature of the fact store in Smart Placement and Smart Underwriting, where once a fact is recorded, it cannot be modified or deleted.

Instead, new facts are added through transactions, creating a complete historical record that supports audit trails and time-travelling queries.

See also: Append-only log, Time-travelling queries, Audit trails.

An open standard that defines communication between development tools and language servers.

Brossa's Language Server implements LSP to provide real-time error checking, code completion, documentation integration, and advanced analysis capabilities in compatible code editors and IDEs.

For further information, refer to https://microsoft.github.io/language-server-protocol/

See also: REPL, Console.

An industry-standard specification for describing REST APIs that Smart Placement and Smart Underwriting use for automatic documentation generation.

The platform generates OpenAPI v3 specifications from API types during the build process, ensuring documentation stays current and enabling auto-generated client-side types for consistency.

For further information, refer to https://www.openapis.org/

See also: API layer.

A user interface technique employed by the policy editor in Smart Placement and Smart Underwriting, where changes are displayed immediately in the interface while evaluation occurs in the background.

This approach improves perceived performance and user experience by showing updates instantly rather than waiting for server confirmation.

See also: Policy editor.

A type system feature that allows functions and data structures to work with multiple types while maintaining type safety.

In Brossa's expressive type system, this enables writing generic specs that can handle different but related data types without sacrificing the benefits of strong typing.

The core user interface component of Smart Placement and Smart Underwriting that automatically generates forms based on spec evaluation results.

The editor provides dynamic form generation, optimistic updates, real-time feedback, and rich widgets to enable efficient data entry and contract management.

See also: Web components, Optimistic updates, Server-side rendering, htmx.

Capabilities for managing collections of policies and risks at scale.

Built on the same specification framework as individual contracts, portfolio management includes aggregation engines for insights and trigger systems for automated decision-making across entire portfolios.

See also: Aggregation engine, Trigger system.

An evaluation methodology where functions have no side effects and outputs depend only on inputs.

In Smart Placement and Smart Underwriting, evaluation takes existing facts as inputs and produces new derived facts and assessments as outputs, without modifying any existing data or external state.

See also: Deterministic, Evaluation.

The automatic updating behavior of contracts in response to new data, similar to how spreadsheets recalculate when cells change.

As facts are added to a contract through various input channels, the spec automatically evaluates and derives new insights, assessments, and calculations.

See also: Evaluation, Forward chaining.

An interactive "Read-Eval-Print Loop" environment for rapid Brossa spec prototyping and testing.

The REPL allows developers and Solutions Engineers to experiment with code, test logic, and debug specs in real-time without needing to create full contracts or specs.

See also: Console, Language Server Protocol (LSP).

One of the two fundamental fact transaction types in the immutable fact store in Smart Placement and Smart Underwriting.

Retraction transactions mark facts as no longer valid or current, while preserving the historical record that they once existed, maintaining the integrity of the append-only log.

See also: Addition, Append-only log.

In Brossa, rules are conditional statements that define logical predicates and associated assessments.

Rules use the format "when [condition] then [assessment] with [reason]" and enable the expression of complex underwriting logic and risk evaluation criteria within specs.

See also: Assessment.

This is the definition of the second term

Here be the description of the second term

A web development approach where HTML content is generated on the server rather than in the browser.

Smart Placement and Smart Underwriting use server-side rendering through htmx to create dynamic forms and interfaces, reducing client-side complexity while maintaining rich interactivity.

See also: htmx, Policy editor.

A structured, scalable platform for programmatically defining, evaluating, and managing insurance products.

Smart Placement replaces document-heavy, manual processes with code-driven workflows, enabling insurers to transition from static operations to dynamic, data-driven decision-making through its use of the Brossa programming language.

A structured, scalable platform for systematically evaluating risks, managing portfolios, and deploying underwriting capital across lead and follow opportunities.

Smart Underwriting automates submission triage, risk scoring, and workflow management through the Brossa programming language, allowing underwriters to focus on high-value decision-making while maintaining alignment with strategic objectives.

In Brossa a spec, or specification, is a programmable schema that defines the structure, rules, and logic of an insurance product or workflow.

Specs act as the blueprint for contracts, describing what data points are needed, how they relate to each other, and what rules govern their evaluation. They can be transacted against and queried like databases.

For further details, refer to:

<!-- * TK_update_Create a spec(how-to-guides/guided-product-configuration.md) -→ * TK_update_Create your first spec(tutorials/create-your-first-spec/README.md) * TK_update_Specifications(explanation/getting-started/the-brossa-language.md#specifications)

See also: Contract.

A logical system used in Brossa’s conditional rules with three possible outcomes: True, False, and Unknown.

Unknown represents cases where insufficient information is available to make a determination, typically when required goals have not yet been fulfilled.

See also: Assessment, Rules.

The ability to query the state of any contract at any specific point in its history.

Because Smart Placement and Smart Underwriting use an immutable, append-only fact store, you can examine what any data point’s value was at a particular timestamp, enabling historical analysis and audit capabilities.

See also: At-time queries, Immutable.

The sophisticated computational engine within Brossa that represents evaluation processes as analysable data structures.

The tracing evaluator supports both forward- and backward-chaining reasoning strategies, while providing full introspection capabilities that let users see exactly how conclusions were reached.

See also: Forward chaining, Backward chaining.

Portfolio-level conditional rules that operate automatically based on real-time portfolio composition and performance data.

Triggers implement automated capacity management, rebalancing decisions, and escalation processes, enabling sophisticated portfolio management without constant manual oversight.

See also: Portfolio management.

The automatic detection and assignment of data types without explicit type declarations.

Brossa's type system can determine the appropriate type for data points based on their definitions and usage, reducing the need for manual type annotations while maintaining type safety.

See also: Bidirectional type-checking.

A type system feature in Brossa that distinguishes between different units and prevents unsafe operations between incompatible measurements.

For example, it prevents accidentally adding US dollars to British pounds by treating Number<"usd"> and Number<"gbp"> as distinct, incompatible types.

A UUID (Universally unique identifier) is a 128-bit identifier that is unique across space and time.

In Smart Placement and Smart Underwriting:

A set of web platform standards that allow the creation of custom HTML elements with encapsulated functionality.

Smart Placement and Smart Underwriting use web components to provide sophisticated controls such as data grids and searchable dropdowns within its policy editor interface.

See also: Policy editor.

A notification mechanism within the public API of Smart Placement and Smart Underwriting and Smart Placement and Smart Underwriting that automatically informs external systems about entity state changes.

Webhooks enable real-time integration by pushing updates to configured endpoints whenever relevant data or contract states change, eliminating the need for constant polling.

See also: API layer.

The Association for Cooperative Operations Research and Development, a global standards organization for the insurance industry.

ACORD develops data standards like GRLC that can be modeled within Brossa specs.

For further information, refer to https://www.acord.org

The use of structured rules and specs to assess risks and generate policy decisions dynamically without manual intervention.

Automated underwriting systems provide traceability of decision-making processes, showing how conclusions were reached through their evaluation logic.

A data standard developed as part of Lloyd’s Blueprint2 initiative for standardizing insurance information exchange.

The CDR defines common data structures and formats for risk and policy information within the Lloyd’s market.

An industry initiative aimed at modernizing and standardizing aspects of the Lloyd’s of London insurance market.

Blueprint2 includes standards like the Core Data Record and focuses on improving market efficiency through digital transformation and data standardization.

For further information, refer to https://www.lloyds.com/about-lloyds/blueprint-two