Skip to main content

Concept & Architecture

The Information Toolbench models metadata and delivers it. Those are not two features; they are one idea, and the shape of the product follows from it. This page explains how the client, the API and the template engine relate — and why each of them refuses to know things the others handle.

No metadata without delivery​

A model that produces nothing is documentation of an intention. Someone writes it, everyone agrees with it, and the platform it describes is built by hand anyway — after which the two drift apart and only one of them is real.

ITB is built so the model is the thing that runs. What you draw becomes artefacts, and those artefacts are what your platform executes.

From model to running platformThe model feeds a generic generator. A pack supplies the rules. The generator writes artefacts — SQL, dbt models, documentation — and those run in the target platform. Swapping the pack changes the output without changing the application.Your modelentities, relations,attributes, typesGeneratorone generic enginefor every outputArtefactsSQL, dbt models,documentationYourplatformTHE PACKtemplates and rules

The engine in the middle knows nothing about Data Vault, about dbt or about any other target. All of that lives in a pack. Installing a different pack changes what comes out the other end without anybody changing the application — which is what makes a second use case a configuration question rather than a release.

One product, three responsibilities​

Client, API and template engineThe client draws and edits, and asks the API what it is allowed to offer. The API is the system of record and decides the capability set. The template engine runs inside the API and turns the model into files. Packs add capabilities and templates at runtime.Clientdraws and edits the modelmenus, wizards, canvasknows no Data Vault,no dbt, no domain at allAPIthe system of recordserves the capability setdecides what thisdeployment may doTemplate engineturns the model into filesruns inside the APIthe rules live in a pack,not in the enginethe modelcapabilitiesPACKS — INSTALLED WHILE IT RUNScapability packs add menus and wizards · template packs add generatorsthe key in your licence decides which of them openModel store & Gitversions, history, recovery

The client is deliberately incurious. It renders what it is given: every menu entry, every wizard and every write is a JSON descriptor the API serves it at runtime. Adding a wizard means adding a descriptor, not a component — and no menu can appear that the server did not offer.

The API is the system of record, and the place where the question "what may this deployment do?" is answered. Your model lives there; the browser keeps a working copy so editing stays immediate, and Model Persistence describes how the two stay in step. Which features exist is decided here too, which is why the Feature Matrix is a property of your deployment rather than of your download.

The template engine is the delivery half, and it lives inside the API because generation needs the model, not the screen. How a pack drives it is in How Generation Works.

The metamodel is what you customize​

Most tools let you fill in a fixed structure. ITB lets you shape the structure itself: which kinds of object exist, how they may relate, what must be recorded about them. That layer is the metamodel, and it is the only one you need to touch to make ITB describe your world.

Metamodel, model and viewThree layers. The metamodel says what may exist and is where customizing happens. The model is what does exist. Viewpoints and the canvas are windows onto that same model, never a second copy of it.Metamodelwhat may exist — the layer you shapeno fork, no release: this is configurationModelwhat does exist — your entities, their attributes, their relationsViewviewpoints and the canvas — windows onto the model, never a second copyentity typesrelation typesviewpointscustom propertiescapability descriptorsconstrainsis rendered as

The visual representation is a view, not a second model. A viewpoint decides which part of the model you are looking at and where the boxes sit; it never holds objects of its own. Remove an entity from a viewpoint and it is still in the model — which is why two people can look at the same model through entirely different windows without either of them owning a private version of the truth.

The same layer carries the capability descriptors: JSON that declares a menu entry, the wizard behind it and the transaction it writes. That is what makes a new modelling action something you declare rather than something somebody builds — see Descriptors and Primitives.

What follows from this​

  • A different output is a different pack, not a different product. The engine does not change when the target does.
  • A different domain is a different metamodel. Types and custom properties are data, so describing a new world is configuration, not development.
  • The edition is decided while it runs. One client build, one image per edition, and the API serves the capability set your licence allows — see the Feature Matrix.
  • What you draw is what gets delivered. There is no second, hand-maintained truth downstream, because the artefacts are generated from the model you are looking at.