Archigov · docs
  1. Docs
  2. Concepts

The Derived Model

How Archigov builds the as-is architecture from sources instead of drawings — application inference, shared services, provenance, verification and generated views.

#Why Derive

A governance tool that needs its model drawn by hand is out of date the day it is finished, and its rules cannot be trusted. Archigov collects the model from sources, so decisions and rules are checked against what actually runs — and an instance is useful within minutes of being connected.

#Sources

SourceWhat it contributes
Azure Resource GraphResources across your subscriptions: type, location, resource group, tags, normalised properties, dependencies
Demo estateA fixture estate for evaluation and training
CSVResources and relations from any inventory you can export
ArchiMate Open ExchangeElements and relations from an existing repository; motivation elements become catalogue drafts
Defender for Cloud, Azure PolicyNot model elements: evidence attached to resources (see Evidence and audit)
Azure DevOpsNot model elements: planned changes (see Azure DevOps)

Importers are sources with provenance, not editors. Collection reads metadata only.

#Applications Are Inferred

How a resource is grouped — deterministic rules in order, each recording its method and confidenceLanes: Inference rule, Grouped as, Human. Steps: Resource collected (Inference rule); Workload tag? (Inference rule); Application (Grouped as); Shared-platform resource group? (Inference rule); Shared service (Grouped as); Naming convention? (Inference rule); Application (Grouped as); Use the resource group name (Inference rule); Application (Grouped as); Move to another application (Human). Transitions: Resource collected to Workload tag?; Workload tag? to Application (yes); Workload tag? to Shared-platform resource group? (no); Shared-platform resource group? to Shared service (yes); Shared-platform resource group? to Naming convention? (no); Naming convention? to Application (yes); Naming convention? to Use the resource group name (no); Use the resource group name to Application; Application to Move to another application (if wrong).Inference ruleGrouped asHumanResource collectedWorkload tag?app, application,service…Applicationtag · 0.92Shared-platformresourcegroup?Shared servicehub, network, identity… ·0.75Namingconvention?rg-<app>-<env>Applicationconvention · 0.70Use the resource groupnameApplicationresource group · 0.55Move to anotherapplicationhuman link survivescollectionsyesnoyesnoyesnoif wrong
How a resource is grouped — deterministic rules in order, each recording its method and confidence

Each resource is assigned to an application, or to a shared service, by deterministic rules, in order:

  1. Tags — the first of app, application, service, workload or system (confidence 0.92).
  2. Shared-platform resource groups — a resource group whose name contains hub, network, connectivity, shared, platform, management, identity or dns becomes a shared service, so hub networks and identity platforms never appear as workloads (0.75).
  3. Resource-group conventions — rg-<app>-<env>-<region> (0.70).
  4. The resource group name itself (0.55).

Each inferred link records its method and confidence. A human can move a resource to another application; that link is then human-owned and survives later collections.

The Applications page
Applications inferred from tags and resource-group conventions, with confidence, owners and verification.

#Provenance and Verification

Every element and relation records:

  • origin — derived (read from a source), inferred (grouped by a rule), human, ai or rules;
  • provenance — which source, which reference, which method;
  • verification — verified or unverified, with who verified it and when.

A content hash is kept for each element. When a collection changes an element's content, its verification drops back to unverified automatically: whoever verified it stood behind the earlier facts. Applications can be verified in one step (Verify All), which verifies the application and its current members.

#Normalised Properties

Resource properties differ by type and API version. Rules read a small set of normalised properties so they do not need to know each schema:

PathMeaning
props.publicAccessWhether the resource accepts public network access
props.minTlsVersionMinimum TLS version accepted
props.httpsOnlyWhether HTTP is redirected to HTTPS
props.osSkuOperating system SKU or version
props.locationAzure region
tags.ownerThe owner tag

#Home Regions

The Applications page flags resources deployed outside the instance's home regions (default uksouth, ukwest, global; change them under Settings → General, or set an empty list to flag nothing). The flag is an advisory hint only — region findings come only from adopted catalogue rules.

#Generated Views

Each application's Design tab shows views generated from the model in ArchiMate notation:

Generated deployment view in ArchiMate notation
A generated deployment view: resources grouped by region, shared services apart, every connection a literal reference.
  • a deployment view — resources as technology elements grouped by region, with external dependencies in a group;
  • an application usage view — which applications use which providers, from literal references between resources.

Views are deterministic: fixed packing rules, orthogonally routed connections, no layout engine and no AI. They cover the physical and technology layer only, because only that layer derives deterministically; the one logical element is the inferred application component itself. The same views export as ArchiMate Open Exchange XML that opens in Archi. Authors and acting board seats can annotate a view or one of its elements.

#Planned Change

The backlog feed adds what is about to change: epics and features from Azure DevOps, or changes logged by hand. They are linked to applications and reviews, and they surface where a decision is missing or a requirement moved after its design was approved.