Glossary
Key concepts and terminology used in Metapad.
Act Method
A Rhai script attached to a node type that runs once per agent per timestep. Used for behavior that touches several properties together — state transitions, reacting to connected agents, conditional updates. The complement to property formulas.
Common confusion
Act methods run AFTER property formulas every timestep, so they see the values formulas just computed. They can override those values by calling agent.set_prop.
Agent
A model element brought to life. Every agent has a type (the node type from your metamodel), and that type defines what properties it tracks over time and how it behaves. Agents read the state of connected agents through links — that's how they coordinate.
Common confusion
An agent is the live (M0) version of a node. Many agents can come from one node — for example, one 'Order' node in your metamodel can spawn hundreds of order agents in a scenario, each with its own lifecycle and values.
Allowed Connections
Rules in the metamodel that define which Node Types can be connected by which Relationship Types. For example: 'Application' --runs_on--> 'Server'. Without an allowed connection, you cannot draw that relationship.
Common confusion
Users often forget to set up Allowed Connections and then wonder why they can't draw relationships between nodes on the canvas.
Asset
An asset is a model element that represents a file or document attached to the model. Assets can hold files like images, PDFs, or other documents. They appear in the Assets section of the Tree View and can be placed on diagrams.
Common confusion
Assets are model elements (like nodes), not just file uploads. An asset exists in the model even without a file attached — the file is optional metadata. Removing a file from an asset does not delete the asset itself.
Business Prototyping
A discipline for managing complex transformation in enterprises, resting on two commitments. **First**, that the best decisions about complex systems emerge when human and machine intelligence work together on shared, explicit models of the world — not augmentation (humans using AI as a tool) but **collaboration**, across shared artifacts that both humans and machines can engage with meaningfully. **Second**, that complex systems cannot be transformed through top-down blueprints — with Karl Popper, the knowledge required to transform a system well is not available in advance; it is produced by the act of transformation itself. We must start from where we are, make changes small enough to be understood and large enough to matter, and learn what the system tells us. A **business prototype** is a shared model that humans and machines can collaborate on, and a working representation of the current state that can be changed incrementally, tested against reality, and evolved alongside the organization. It is the instrument of piecemeal transformation in complex socio-technical systems — and equally the instrument of greenfield design where a new system is being shaped from the start.
Common confusion
Business prototyping is not the same as a digital twin. The prototype is the activity and the lightweight working model — dynamic, iterative, exploratory. A digital twin is what a prototype matures into once it gains enough fidelity, persistence, and live data integration to serve as an ongoing operational artifact. Equally, business prototyping is not 'business transformation' in the McKinsey/Accenture sense — it is the methodology and instrument that makes transformation incremental, testable, and learnable rather than a top-down blueprint.
Diagram
A visual view of a subset of your model. A diagram shows selected nodes and their relationships on the canvas. One model can have many diagrams, each showing different aspects.
Common confusion
A diagram is NOT the model — it's a VIEW of the model. Deleting a node from a diagram does not delete it from the model. The model can contain elements not shown on any diagram.
Digital Twin
A digital representation of a real-world system, process, or organization. Metapad models serve as digital twins that can be queried, analyzed, and kept in sync with reality.
Common confusion
A digital twin is not just a static document — it's a living model that evolves with the real system.
Knowledge Graph
A network of entities (nodes) connected by typed relationships (edges) where each connection is explicit, queryable, and traversable. Knowledge graphs make relationships first-class — not implicit foreign keys (databases), not buried in prose (documents), not assumed in your head (spreadsheets). This unlocks multi-hop, path-based, and pattern-matching queries that other data structures cannot answer. Every Metapad model is a typed knowledge graph that AI tools can reason over reliably.
Common confusion
A knowledge graph is not a network diagram or visualization — those are projections of the graph. The graph itself is the underlying typed structure. A knowledge graph is also not the same as an ontology: ontologies are richer formal specifications geared toward open-world reasoning, while knowledge graphs are the data structure (typically driven by a metamodel or ontology).
Live Twin (M0)
The live layer of your model. A twin picks a slice of your model (which node types are in scope) and brings it to life over time: historical data, current state, and future projections all live side-by-side. It builds on top of your existing types and instances — those become the foundation for the live picture.
Common confusion
A live twin is not just a snapshot — it's a running simulation scoped to a part of your model. Multiple twins can exist for the same model (for example, 'HR Operations' and 'Supply Chain'), each with its own timeline and behavior.
Metamodel (M2)
The schema layer that defines WHAT TYPES of elements can exist in your model. Contains Node Types, Relationship Types, and Allowed Connections. Think of it as the 'template' or 'blueprint' for your model.
Common confusion
Users often confuse the metamodel (types/schema) with the model (instances). The metamodel defines 'Person' as a type; the model contains 'Alice' as an instance of Person.
Model (M1)
The instance layer containing actual data — specific nodes and relationships that conform to the metamodel. If the metamodel defines 'Server' as a node type, the model contains 'web-server-01' as a concrete Server instance.
Common confusion
Users sometimes try to create instances without first defining types in the metamodel.
Modeling
The practice of creating structured representations of real-world systems using nodes (entities) and relationships (connections). In Metapad, you define a schema (metamodel) and then create instances that conform to it.
Common confusion
Users sometimes confuse 'modeling' with 'drawing'. Modeling is about structured data with types and constraints, not just visual diagrams.
Node
An instance in the model (M1) that conforms to a Node Type. Each node has a label, optional description, and property values defined by its type.
Common confusion
Nodes are instances of Node Types. You must create the Node Type first before you can create Nodes of that type.
Node Type
A type definition in the metamodel (M2). Defines a category of elements with specific properties. For example, 'Server', 'Person', or 'Requirement' are node types.
Common confusion
A Node Type is the TYPE definition (like a class), not an instance. 'Server' is a Node Type; 'web-server-01' is a Node (instance).
Ontology
A formal representation of knowledge within a domain — what classes of things exist, what properties they have, and what relationships hold between them. Ontologies emerged from philosophy and AI knowledge representation; in computer science they support **open-world reasoning** (if something isn't stated, it's unknown — not false), enabling inference and cross-domain knowledge integration. The mature standards stack: OWL for ontology definition, RDF for data, SPARQL for queries, SHACL for validation. Metapad uses metamodeling as the visual interface with ontology-grade expressiveness underneath.
Common confusion
Ontologies and metamodels overlap heavily — both define classes, relationships, and properties. The differences are emphasis, not category: ontologies favor open-world reasoning and knowledge integration; metamodels favor closed-world validation and engineering rigor. The choice between them is about what you need to do, not about which tradition you come from.
Property Formula
A short Rhai expression that computes a property's value at every timestep. Like a spreadsheet cell formula, but it can also read other agents through the graph. Defined on the node type, so all agents of that type share the same formula by default.
Common confusion
A formula computes one property's value at one timestep. To update multiple properties together, or to react to other agents' state, use an act method instead.
Relationship
An instance in the model (M1) — a concrete connection between two nodes. For example, 'web-server-01 runs_on linux-host-03'.
Common confusion
You can only create relationships between nodes whose types have an Allowed Connection defined for that relationship type.
Relationship Type
A type definition in the metamodel (M2) that defines a kind of connection. For example, 'runs_on', 'manages', or 'depends_on'. Relationship types define what connections are possible.
Common confusion
Relationship Types need Allowed Connections to specify which Node Types they can connect.
Scenario
A what-if projection inside a twin. You can have many scenarios per twin — 'Baseline', 'Optimistic', 'Pessimistic' — and compare them side-by-side. Each scenario defines its own timeline (start, end, step size) and contains its own agents, links, and simulation diagrams.
Common confusion
Each scenario is fully independent — agents, links, and diagrams belong to one scenario. Editing values in 'Aggressive Hiring' does not affect 'Baseline'.
Time Series
A property's values across time. Each agent property has a row in the time series grid; columns are timesteps. Cells can be filled in manually (spreadsheet mode) or computed by a formula (rule-driven mode) — the two are interchangeable in the same twin.
Common confusion
If you don't enter a value at a given timestep, the previous timestep's value carries forward. There's no 'gap' — only the explicit changes you record.