Nasdanika Models

An Ecore micro-model of decision binding: the open questions of a solution, the alternatives at each of them, who is accountable for committing one, and the record of what was committed, when, by whom, and on what evidence. Ivar Jacobson described software development as the process of binding decisions until they become executable; Software Factories and Software Product Line engineering made that operational with variation points, alternatives, criteria, and binding time. This is that vocabulary as a model, one floor above decision analysis.

An architecture decision record says which alternative was chosen. This model additionally keeps the ones that were not, the criteria they were judged against, the decisions the choice opened downstream, and the condition under which it is to be revisited - so a decision can be retraced and rebound instead of re-argued.

Position in the tower

The aspect spine of the Nasdanika model tower runs

nxcore < role < iam < seal < lifecycle < accounting < decision analysis < decision binding < governance < work < requirements < architecture < threat

and this model sits directly above decision analysis for a narrow reason: a binding commits an analyzed Alternative into a variation point. Alternative here extends the analysis floor’s Alternative, so a candidate is judged, evaluated, and ranked by machinery that already exists; Embodiment and VariableElement extend Comparand, so whole configurations are analysis subjects too. VariationPoint and Binding extend lifecycle’s Staged, which brings dated sojourns, IAM-backed access control, and seal signatures with them: a binding is signable, and a signed binding is non-repudiable provenance for every floor above. Binding.boundBy is an IAM Subject, so the authority that bound may be a person, a service account, or an agent, with no second reference type.

The pairing with the floor below is deliberate and works in both directions. Analysis without binding is a first-class use - a record of judgments needs no variation point. Binding without analysis is equally first-class: Binding.analysis is optional, and its absence means a fiat or default binding - a legitimate record, visibly unanalyzed. The model refuses to make honesty expensive.

VariableElement is the aspect extension point this floor contributes upward: an element that carries its own variation points and the bindings that resolved them. That is what makes an ADR attached to the architecture element it decides rather than filed next to it, and it costs nothing until the first variation point is declared.

Competitive landscape

Six camps model parts of this. Each is strong on one axis and silent on the others.

ADR tooling. Nygard-style ADRs, MADR, adr-tools, Log4brains, adr-viewer, ADRs rendered by Structurizr and Backstage TechDocs. This is the industry standard, it is genuinely good, and it is the on-ramp this model is designed to receive rather than replace - the front-matter fields of a decision record map onto the classes here almost one for one. Its limits are structural: a directory of Markdown files is a list, and decisions are a graph. Supersedes links exist by convention, depends-on and opens do not; the alternatives that lost survive as prose paragraphs rather than as objects that can be re-evaluated; the criteria are not comparable across records; and nothing connects the record to the element it decides, so drift between the ADR and the architecture is undetectable by construction.

Variability management and product lines. pure::variants, BigLever Gears, FeatureIDE, UVL, Clafer, Kconfig, and the FODA feature-model lineage. The closest structural prior art, and better than this model at constraint expressiveness over large feature trees. What they model is the space, not the deciding: a feature model has no accountable party, no binding date, no rationale, no analysis behind a selection, and no revisit trigger. They are also embedded-and-automotive tool suites, priced and shaped accordingly. The academic decision-oriented strand - DOPLER, decision modeling by Dhungana and Rabiser - is nearest of all in spirit and has no adoption path outside research tooling.

Resolvers, wizards, and flag platforms. Maven and apt dependency resolution, Eclipse P2, Nix, Spring Initializr, Terraform variables and Helm values, LaunchDarkly and Unleash. Each of these is decision binding, at one binding time, over one narrow slice of the space, with the rationale discarded. BindingTime - design, build, deployment, run - is what puts them on one axis: a feature flag is a run-time binding of a variation point, and the model records it as the same kind of fact as an architecture choice made two years earlier.

Decision intelligence and approval workflow. Cloverpop, Loomio, Quantellia, decision logs in Confluence and Notion, CAB approvals in ServiceNow. They record outcomes and consensus. The design space, the alternatives, and the dependency structure are not in the data model, so the second decision cannot reuse anything from the first.

Experiment tracking and hyperparameter optimization. MLflow, Weights & Biases sweeps, Optuna, Ray Tune, and the evaluation harnesses that grew up around GenAI - promptfoo, DeepEval, Inspect, DSPy optimizers. These are how bind-by-measurement is actually practiced, and they are complements rather than rivals: they produce runs and metrics. What stays outside them is the decision the run was supposed to bind - which variation point, whose authority, against which criteria, until when. Exploration, Embodiment, and BindingMode.bindByMeasurement are the adapter: the sweep produces embodiments, the harness result becomes an evaluation on the analysis floor, and the binding cites it.

The real competitor: the slide deck, the wiki page, and the spreadsheet. As always, the incumbent is cheaper for producing one answer once, and as always the wedge is everything after the first answer. The specific damage these formats do here is worth naming, because it is usually mistaken for a character flaw in people: office formats hold conclusions well and design spaces badly. Keeping three alternatives alive in a deck means maintaining three parallel copies by hand, so the carrying cost of optionality is paid in editing, and the medium quietly pushes toward a single early answer. Revisiting the decision a year later is then archaeology - reconstructing from memory why the choice was made and what else was on the table. Much of what looks like premature commitment is the tooling billing for alternatives.

The position none of the six occupies: an open design space attached to the elements it varies, with binding authority, binding time, and binding mode typed, evidence cited from a real analysis, and a lineage that survives rebinding.

What a typed model adds

Decisions form a graph, not a list. An Alternative contains Transitions to the VariationPoints it opens; a variation point collects incomingTransitions, so a database choice and an operating-system choice can jointly open a certification decision, and entryPoints - variation points with nothing pointing at them - is derived rather than curated. The everyday analogy is a configuration wizard where each choice determines what appears on the next page; a project is a very large wizard, and the craft is walking it in the right order. A transition may carry a condition, so a branch can depend on parameter values rather than on the alternative alone.

Unbound is a modeled state, not an absence. VariationPointState runs identified, open, tentative, bound, superseded, retired. Identified is the cheapest and most underrated record in the model: a decision we know exists and have not made. BindingMode then says how it will be resolved - bindNow when the inputs exist, bindOnTrigger when a named input is missing, bindByMeasurement when only running the thing can settle it - and bindingTrigger names the input, so “we are not ready” becomes a queryable claim with an owner instead of a hallway sentiment. Deciding late is not the failure. Deciding without inputs and deciding by default are.

Binding time is itself a decision. BindingTime records whether a choice is fixed at design, build, deployment, or run time. Late binding is what a product line is made of, and it has a cost; making it an attribute puts that trade in the record rather than in an implementation detail discovered later.

Authority is written down before the answer is. Responsibility assigns a Role from the role floor to a variation point, with the intended constraint of exactly one accountable party. The failure this addresses - a decision with seven-figure run-cost implications bound by whoever speaks first, loudest, or highest in the org chart - is not solved by better manners; it is solved by the question “who binds this?” having a written answer before the argument starts. A bound decision then has a defined path to change: a rebinding request carrying new evidence, addressed to a named party, rather than recurring debate by people without the authority to rebind.

A binding is a record, not a status field. Binding carries the selected alternative, its parameterValues, boundBy, boundOn, rationale, the analysis that informed it, a revisitTrigger, and supersedes. The superseded binding is kept, with its rationale, which is what makes this version control for decisions: history and diffs where office formats keep only the final working tree. Cheap rebinding is the payoff that dwarfs the rest - a new model is released, a building block appears, a price drops, and the move is to retrace to the variation point, add the alternative, re-evaluate it against criteria already on file, and rebind with lineage. revisitTrigger is what turns a bet into an honest bet: a tentative binding with no named revisit condition is a silent one.

Adding an alternative is contribution, not conflict. Because alternatives are objects at a variation point rather than positions in an argument, a strong proposal enters as a well-developed alternative competing on stated criteria. That is a better outcome for a good idea than a decree, because it survives scrutiny with its credibility intact - and it is the structural answer to advocacy that has attached itself to a technology rather than to a fit.

One embodiment is a point; the space is the asset. An Embodiment is a partial or complete set of bindings over a decision space - one configuration out of the thousands the space admits. Several embodiments of one space are product-line members: a premium tier and a standard tier share the architecture and differ only in bindings. Because Embodiment is a Comparand, narrowing thousands of them is multi-criteria analysis over comparands, not a new mechanism.

The space is executable in three directions. Forward, walk the graph, enumerate valid combinations of alternatives and parameter values, materialize embodiments, and narrow them by analysis until the Pareto surface remains - the choice among frontier points is then a business decision made with full visibility. Backward, state a DesignSpaceRegion as CriterionBounds - under X dollars a month, p95 latency under Y - and get back the embodiments that fit, which is the filter experience of any online catalog and what package resolvers already do for a narrow slice of the space. Pull, run an Exploration with a strategy (exhaustive, sample, sweep, adaptive) and a budget, producing candidates at the pace evaluation can afford. For GenAI decisions every point costs harness runs and real money, so backpressure is not an implementation detail, it is cost control.

The aspect costs nothing until used. VariableElement gives any element above this floor its own variationPoints and bindings. An architecture element carries the ADRs that shaped it where drift is detectable; a control carries the treatment choice that produced it; a capability provider carries the selection that put it there.

Applications

Architecture decisions that cannot drift

The base case. Variation points and bindings hang off the architecture elements they decide, so the record and the thing recorded are elements of one graph in one repository, versioned in the same commits and reviewed in the same pull request. “Which decisions shaped this component”, “which components does this decision touch”, and “which decisions are still open on this subsystem” become queries. The generated site renders the decision log; the model is what keeps it from becoming fiction.

GenAI and agentic solutions, where analysis is not enough

For conventional systems an experienced architect binds many decisions analytically. For GenAI solutions a large class of decisions - model selection, routing policy, prompt and context strategy, tool granularity, retrieval configuration - lives in a space where cost, latency, and quality trade against each other, and the optimum is located by measurement rather than by argument. Using the strongest model everywhere is too expensive; using a local model everywhere is too slow or too weak. The right binding is usually a routing policy on a measured cost/quality/latency frontier.

Two consequences are modeled directly. Such decisions are bindByMeasurement with an evaluation harness as the binding trigger, and their bindings cite an analysis whose evaluations carry measured rather than judged evidence. And they decay: the model landscape shifts quarterly, so revisitTrigger - “rebind when a model at capability X drops below price Y”, “quarterly model landscape review” - is part of the binding rather than an afterthought. Composed with the agent, MCP, and AI governance models, the configuration an agent runs on, the decision that put it there, and the evidence behind it are three views of the same elements.

Product lines, tiers, and channels

Deliberately leaving variation points open with several supported alternatives turns one product into a family: customer tiers binding cost and quality differently from one architecture, partners and channels binding integration and deployment differently without forking a codebase. A documented decision space is what makes reuse in a new business area an extension; a single undocumented embodiment is what makes it a rewrite.

Governance, risk treatment, and waivers

Treatment selection is a variation point - accept, mitigate, transfer, avoid - and the chosen treatment is a binding a governance waiver can cite, with the accountable party and the date already in the record. Compensating-control choices work the same way. Risk acceptance stops being an attribute somebody set and becomes an attributable, dated, signable act with its rationale attached.

Legacy modernization

The R-menu - rehost, replatform, refactor, rearchitect, rebuild, replace, retain, retire - is a variation point per application, with alternatives scored against criteria and the choice bound, so the migration decision and the estate model cannot drift apart. This is how the BW5 model uses the floor, and the same shape carries a system-of-record programme, where “which system becomes the record for which term” is bound per term and the rationale outlives the programme.

Vendor, provider, and platform selection

Composed with capability and product management, provider selection is an analysis over comparands the tower already holds, committed through a binding that cites it. Re-tendering two years later starts from the criteria and alternatives already on file, with the previous binding and its rationale preserved as lineage rather than reconstructed from memory.

Decision rights and organizational design

The org design model defines decision rights over the variation points on this floor: a decision right is the authority to bind a class of variation points, which makes “who decides what” checkable against the record of what was actually bound, by whom. Delegation, escalation, and the gap between the org chart’s answer and the record’s answer become queries rather than opinions.

Requirements as a region of the space

A requirement bounds the design space; a binding picks a point in it. Stating requirements as a DesignSpaceRegion makes “which configurations still satisfy everything we have promised” a filter, and makes a requirement change visible as the set of bindings it invalidates.

Onboarding and audit

One record serves two audiences that are usually served by separate artifacts. A new joiner reads why the system is the way it is, including the alternatives that were considered; an auditor reads who was accountable, what evidence was cited, and when it was signed. Both are byproducts of having recorded the decision once, in a form that did not require a meeting to produce.

Authoring and loading

The practice this model supports has to cost minutes per decision, not hours, and must never block anyone who is ready to act. It therefore starts in Markdown and grows without rework:

  • ADR files - MADR or Nygard-style records in the repository next to the work, with front matter for id, status, accountable party, binding and revisit triggers, depends-on and opens. Those fields are the model: statuses map to VariationPointState, the accountable party to a Responsibility, the links to Transitions. The first stage is a decision backlog anyone can read; the second is the same files loaded as a graph, with blocked-by and awaiting-input reports generated from them.
  • Draw.io for the decision graph as an authoring surface, via the drawio model - a decision map drawn in a workshop loads as variation points and transitions rather than being redrawn as one.
  • Excel for decision backlogs and option matrices, which is where they already live.
  • Evaluation harnesses and HPO runs as the source of measured evidence for bindByMeasurement decisions, arriving as evaluations on the analysis floor.
  • Resolvers and configuration - existing build, deployment, and feature-flag configuration read as bindings already in force, which is usually how the first realistic decision space gets populated.

The productive move on a project still waiting for requirements is exactly this: enumerate the variation points, alternatives, and criteria, and assign accountability. When the inputs arrive, binding is fast because the evaluation structure already exists. Waiting time becomes readiness.

Model overview

Area Types
Extension point VariableElement (anything that varies; extends analysis Comparand, contains variationPoints and bindings)
Space DecisionSpace (root: variation points, shared criteria, roles, embodiments, explorations, analyses, derived entryPoints)
Openness VariationPoint (VariationPointState, BindingMode, BindingTime, bindingTrigger), Responsibility (RACI, role)
Candidates Alternative (extends analysis Alternative), Parameter, Transition (guarded by condition)
Commitment Binding (boundBy, boundOn, rationale, analysis, revisitTrigger, supersedes), ParameterValue, Embodiment
Execution Exploration (ExplorationStrategy, budget), DesignSpaceRegion, CriterionBound
Reused, not redefined analysis Comparand, Alternative, Criterion, Analysis; lifecycle Staged; iam Subject; role Role; nxcore ModelElement, documentation, markers

Two seams are open by design and stated rather than hidden. RACI is a four-value enumeration where the tower’s own rule says vocabularies are instance data - it stands in for role-model engagement, which is the general mechanism and the direction of travel. And VariationPointState is hand-rolled where the lifecycle floor already provides stages, sojourns, and guarded transitions; retiring it into a variation-point lifecycle would make “how long did this decision sit open, and who moved it” a query rather than an attribute.

What sits on top

Everything above this floor decides something, and in the spine ordering everything above reaches this floor by inheritance rather than by declaration. Governance sits directly above - treatment and compensating-control choices as bound variation points cited by waivers - and through it work, requirements, architecture, and threat elements arrive already able to carry their own decisions. The estate and surface models follow: Maven modules, BW5 processes, system-of-record fields, UI and Bootstrap elements all carry the decisions that produced them - which is also what makes agent-generated artifacts reviewable, because the choice, its author, and its rationale are attached to the thing produced.

Resources