Instance Maps Programming Guide

Overview#

An instance map is a template. You write a definition; Atlas expands it into the concrete instances your queries return. This guide is about authoring those definitions as data: the exact shape of a .map.json file, the expansion arithmetic that decides how many instances you get, the six property strategies, and the write-then-compile workflow an import pipeline has to follow.

It is written for a developer generating instance maps from a script, an ETL job, an asset register export, or an agent tool - anyone who will never open the Atlas drawer.

Three companion articles own material this guide does not repeat:

• Instance Maps - the concept model and the browser workflow: the three expansion shapes, what a variable is, what compile does to instances that disappear.
• Property Sourcing Strategies - Static, Bound, and Calculated - what each strategy means, the per-connector binding-path shape, compound properties, and why a bound property reads 0.
• Atlas API - Instance Maps - routes, verbs, request and response bodies, status codes, and the compiled-instance read endpoints.

Six shapes to get right#

Each of these is accepted without an error and then does not do what you expect.

The inline Relationship-Instance edge sub-resource wire bodies are superseded along with the inline relationships[] authoring form. Author each connection as its own instance map definition.

The file#

Definitions live in the domain's Git repository at instances/{stem}.map.json. One file holds many definitions. The root must be a JSON array.

<domain>/
  ontology.jsonld
  instances/
    line-a.map.json
    topology.map.json

The file format, and the asymmetry that will bite you#

Atlas reads a .map.json file with these rules:

The API uses different rules. It also uses camelCase names, omits nulls and writes enum values as camelCase strings, but it does not refuse unknown property names: an unrecognised JSON property on a request body is ignored.

Because the API drops unknown members before persisting, a definition written through the API always lands on disk as a parseable file. Round-tripping is therefore not a test that your intent survived - only that your JSON was accepted.

The two I-A1 messages you will see when a hand-written file is wrong:

Instance map file root must be a JSON array; got Object.

Instance map file is not parseable JSON at line 14, column 7: ...

The definition record#

A definition accepts exactly eleven members. The file on disk and the API request body carry the same field set.

id, name, type and instanceId are positional constructor parameters on the request record. Persisted-file validation is narrower: I-A2 enforces only id, type and instanceId. There is no rule for a missing name in a file.

Singleton definition#

No sources, and no map entry that produces more than one value. Produces exactly one instance.

[
  {
    "id": "brewery-site",
    "name": "Brewery Site",
    "type": "urn:atlas:ontology:brewing:Site",
    "instanceId": "urn:atlas:instance:brewing:site-riverside",
    "label": "Riverside Brewery",
    "properties": {
      "urn:atlas:ontology:brewing:siteCode": [
        { "type": "StaticStrategy", "value": "RVS" }
      ]
    }
  }
]

Mode detection is mechanical: sources non-empty wins and selects RowsetTemplate; otherwise any map entry whose data parses to more than one value selects StaticTemplate; otherwise Singleton. There is no mode field to set.

Expansion is linear, not Cartesian#

Atlas counts the values each map entry produces and takes the largest count as the number of instances. For instance i it reads the i-th value of every entry at the same time.

Read map entries as parallel columns of a table, not as nested loops. The longest column sets the row count. Every other column is read at the same row index. Two entries of three values each give you three instances, not nine.

Past the end of a shorter column, wrap decides:

An example that does not do what it looks like#

{
  "id": "cooling-towers-broken",
  "name": "Cooling Towers",
  "type": "urn:atlas:ontology:plant:CoolingTower",
  "instanceId": "urn:atlas:instance:plant:CT-[Area]-[Num, 00]",
  "map": [
    { "name": "Area", "data": "North, South" },
    { "name": "Num",  "data": "1-3" }
  ]
}

The old guide claimed six instances. Here is the actual arithmetic. Area parses to two values, Num to three, so instanceCount is 3:

Three instances, two of them in the South, and no CT-North-02 anywhere. Setting "wrap": true on Area changes index 2 to North and still yields three. ### The corrected form that produces what you wanted

Make every column the same length. Six cooling towers, three per area:

{
  "id": "cooling-towers",
  "name": "Cooling Towers",
  "type": "urn:atlas:ontology:plant:CoolingTower",
  "instanceId": "urn:atlas:instance:plant:CT-[Area]-[Num, 00]",
  "label": "[Area] Cooling Tower [Num]",
  "map": [
    { "name": "Area", "data": "North*3, South*3", "wrap": false },
    { "name": "Num",  "data": "1, 2, 3, 1, 2, 3", "wrap": false }
  ],
  "properties": {
    "urn:atlas:ontology:plant:fanCount": [
      { "type": "StaticStrategy", "value": 4 }
    ]
  }
}

North*3, South*3 expands to six values (North, North, North, South, South, South); 1, 2, 3, 1, 2, 3 expands to six. instanceCount is 6, and you get CT-North-01, CT-North-02, CT-North-03, CT-South-01, CT-South-02, CT-South-03.

For a generator, the rule is: emit fully materialised parallel columns of equal length. wrap exists for the deliberate cycling case rather than as padding.

The alternative, and usually the more readable one, is one definition per group:

[
  {
    "id": "cooling-towers-north",
    "name": "Cooling Towers - North",
    "type": "urn:atlas:ontology:plant:CoolingTower",
    "instanceId": "urn:atlas:instance:plant:CT-North-[Num, 00]",
    "label": "North Cooling Tower [Num]",
    "map": [ { "name": "Num", "data": "1-3", "wrap": false } ]
  },
  {
    "id": "cooling-towers-south",
    "name": "Cooling Towers - South",
    "type": "urn:atlas:ontology:plant:CoolingTower",
    "instanceId": "urn:atlas:instance:plant:CT-South-[Num, 00]",
    "label": "South Cooling Tower [Num]",
    "map": [ { "name": "Num", "data": "1-3", "wrap": false } ]
  }
]

Three instances each, six in total, and the identities are obvious from the file.

The map array#

The data grammar#

Atlas tries the four patterns below in order, then falls back to a comma split, then to a single value. A data value never fails to parse.

Two rules a generator has to encode explicitly:

Parse being total is why the validator does not reuse it: I-A7 duplicates the grammar precisely so it can reject garbage that Parse would happily treat as a single value.

Placeholders#

The syntax is [Name], optionally [Name, Format]. The regex is \[(\w+)(?:,\s*([^\]]+))?\].

The format specifier is a leading alpha prefix plus a .NET numeric format. A non-numeric value is returned unchanged rather than erroring.

Placeholders are interpolated into:

An unknown placeholder in a binding path or a static value is not a save-time violation. It throws during expansion:

Placeholder references undefined map entry: [Cap] in template: [Cap]

Every variable must be referenced#

I-A8 runs in both directions. An unresolved placeholder is a violation, and so is a declared variable nothing uses:

map[] entry name 'Area' is an orphan — no instanceId, label, property strategy, or relationship template references it.

References from instanceId, label, source, target, any strategy bindingPath or string value, an argument value, or anything nested inside a CompositeStrategy's members all count.

Property strategies#

properties maps a full property URI to a list of strategy entries. Both halves matter.

The key must be a full URI, or the instance map reports rule I-A4:

Property key 'Site' is not a full URI. Property keys must start with 'urn:atlas:ontology:' (short names are dropped at compile).

The message means what it says. A short key is accepted by the API, reported as a violation, and then dropped at compile - the property simply does not exist on the instance, and no error mentions it again. There is one URN namespace for all six ontology kinds: urn:atlas:ontology:{scope}:{LocalName}. There is no urn:atlas:fn:, urn:atlas:prop:, urn:atlas:class: or urn:atlas:rel:. Instance identities use the separate urn:atlas:instance: base.

The value is a list because strategies are time-intervalled. Each entry may carry validFrom (an ISO-8601 instant); omitted means from the beginning of time. If a property has one source for its whole life, the list has one entry.

The six strategy types#

The discriminator is type, and the allowlist has exactly six members:

Anything else is I-A5:

Strategy type 'Manual' is not recognised. Allowed values: StaticStrategy, BoundStrategy, CalculatedStrategy, NullStrategy, CompositeStrategy, ReferenceStrategy.

I-A5 and I-A6 recurse into CompositeStrategy.members, so a nested member entry is held to the same allowlist and the same required-field checks.

Full entry shape:

bindingPath is not a URI#

states the format on the record itself:

BindingPath is a connector binding path — slash-delimited segments starting with the connector's instance id, never a 'scheme://' URI — and supports placeholder interpolation (e.g. 'historian-juice-factory/The Juice Factory/131-TT-[Num].PV').

"urn:atlas:ontology:juice-factory:temperature": [
  { "type": "BoundStrategy",
    "bindingPath": "historian-juice-factory/The Juice Factory/[Tag]" }
]

After interpolation, the concrete path must match a path a connected connector has advertised, or match one of that connector's templates. An unresolvable path is skipped at subscription time.

Two documented exceptions to the leading-instance-id rule: the HTTP/REST plugin advertises each endpoint's configured BindingPath verbatim with no instance-id prefix, and the Timebase Reference plugin advertises fixed fake/... paths. For those two, use the path exactly as the plugin advertises it.

Per-connector path shapes are in Property Sourcing Strategies.

Calculated arguments#

"urn:atlas:ontology:juice-factory:temperatureCelsius": [
  {
    "type": "CalculatedStrategy",
    "functionUri": "urn:atlas:ontology:juice-factory:FahrenheitToCelsius",
    "arguments": [
      { "type": "propertyRef",
        "parameter": "urn:atlas:ontology:juice-factory:param/fahrenheit",
        "propertyUri": "urn:atlas:ontology:juice-factory:temperature",
        "order": 0 }
    ]
  }
]

functionUri is an ordinary ontology URI: urn:atlas:ontology:{scope}:{FunctionName}. urn:fn:... does not resolve and fails I-B9.

Static values, including compounds#

Placeholder interpolation recurses into object and array leaves, which is how a compound property gets a per-instance static value. From a shipped example:

"urn:atlas:ontology:juice-factory:temperature": [
  {
    "type": "StaticStrategy",
    "value": {
      "Timestamp": "2026-04-22T08:30:00Z",
      "Value": "[Temp]",
      "Quality": "Good"
    }
  }
]

Relationships are their own instance maps#

A relationship is not a sub-list inside an entity definition. It is an ordinary instance map whose type is a relationship archetype, carrying top-level source and target.

Taken verbatim from tests/.../test-fixtures/domains/relationship-test/instances/fixtures.map.json:

{
  "id": "feeds-pump01-tank01",
  "name": "Feeds-Pump01-Tank01",
  "type": "urn:atlas:ontology:juice-factory:Feeds",
  "instanceId": "urn:atlas:instance:juice-factory:feeds-pump01-tank01",
  "source": "urn:atlas:instance:juice-factory:pump-01",
  "target": "urn:atlas:instance:juice-factory:tank-01",
  "properties": {
    "urn:atlas:ontology:juice-factory:flowRate": [
      { "type": "StaticStrategy", "value": 2.5 }
    ]
  }
}

Four rules govern the endpoints.

1. Both, or neither. The implementation is three lines:

var hasSource = !string.IsNullOrEmpty(def.Source);
var hasTarget = !string.IsNullOrEmpty(def.Target);
if (hasSource == hasTarget) return; // both present (relationship) or both absent (entity)

Declaring one without the other is I-A9:

A relationship instance map must declare both 'source' and 'target'; 'target' is missing.

2. They carry instance identities, not definition ids. Atlas matches each endpoint against the expanded instance URNs across the whole domain. Those come from the interpolated instanceId, not the definition id. Putting a definition id there is a dangling endpoint, I-B6:

Relationship instance 'feeds-pump01-tank01' references target 'urn:atlas:instance:juice-factory:tank-1', which does not match any expanded instance id in the domain.

Watch the padding. tank-01 and tank-1 are different strings.

3. They are templates. Both accept the same [Name] syntax as instanceId and are interpolated once per expanded row, so one definition creates many edges. Resolution runs over the full instance set, independent of any one entity's row, which is what lets the two ends come from different definitions and different files. The class summary calls that decoupling "the load-bearing half" of the design.

{
  "id": "area-contains-ct",
  "name": "Area Contains Cooling Tower",
  "type": "urn:atlas:ontology:plant:AreaContainsCoolingTower",
  "instanceId": "urn:atlas:instance:plant:contains-CT-[Area]-[Num, 00]",
  "map": [
    { "name": "Area", "data": "North*3, South*3", "wrap": false },
    { "name": "Num",  "data": "1, 2, 3, 1, 2, 3", "wrap": false }
  ],
  "source": "urn:atlas:instance:plant:area-[Area]",
  "target": "urn:atlas:instance:plant:CT-[Area]-[Num, 00]"
}

Six edges, matching the six cooling towers above. Both area-North and area-South have to exist as expanded instances somewhere in the domain, or every row raises I-B6.

4. Edge properties are ordinary properties. A relationship's properties block works exactly like an entity's, as the fixture shows. There is no separate edge-property surface; the inline edge sub-resource wire bodies were retired alongside relationships[].

Two more semantic rules apply: I-B5 requires the type to be a relationship archetype (a class transitively under RelationshipBase or ContainsBase), and I-B7 checks each resolved endpoint's type against the archetype's SourceType / TargetType constraints.

Building instances from a connector: sources#

sources turns one definition into one instance per row a connector returns. This is how you build a domain from an asset register or a tag catalog rather than enumerating assets in the file.

{
  "id": "bound-machines",
  "name": "Bound Test Machines",
  "type": "urn:atlas:ontology:juice-factory:Machine",
  "instanceId": "BoundMachine-[Num, 00]",
  "sources": {
    "fillers": {
      "bindingPath": "historian-juice-factory/The Juice Factory/FillerTemps",
      "transforms": {
        "name": { "regex": "(?<Area>\\d+)\\-(?<Instrument>\\w+)\\-(?<FillerNumber>\\d+)\\.PV" }
      }
    }
  },
  "map": [
    { "name": "Num", "data": "[fillers.FillerNumber]", "wrap": false },
    { "name": "Tag", "data": "[fillers.name]", "wrap": false }
  ],
  "properties": {
    "urn:atlas:ontology:juice-factory:temperature": [
      { "type": "BoundStrategy",
        "bindingPath": "historian-juice-factory/The Juice Factory/[Tag]" }
    ]
  }
}

Behaviour worth encoding in a generator:

• A row whose transform regex does not match is dropped, not passed through. A slightly-too-strict regex produces fewer instances than the source has rows.
• An empty rowset, or a rowset where every row is dropped, produces zero instances and is logged as a warning. The compile still reports success.
• A definition may declare several sources, but map may reference only one of them. Referencing two throws; I-B14 should have caught it first.
• Rowset expansion needs a connector round-trip, so it only runs on the async path. A synchronous expansion of a RowsetTemplate definition returns empty by design.

Validation rules a map author trips#

Instance rules split into I-A* (format, checked against the persisted file) and I-B* (semantics, checked against the ontology and the expanded instance set). All of them live under Infrastructure/Persistence/Validation/.

GET /api/v1/branches/{branch}/domains/{domain}/validation returns the authoritative current list for a domain.

Writing by code#

The full route table, request and response bodies and status codes belong to Atlas API - Instance Maps. What a generator needs to know:

POST   /api/v1/branches/{branch}/domains/{domain}/instance-maps/                       201
GET    /api/v1/branches/{branch}/domains/{domain}/instance-maps/                       200
DELETE /api/v1/branches/{branch}/domains/{domain}/instance-maps/{fileName}             204
GET    /api/v1/branches/{branch}/domains/{domain}/instance-maps/{fileName}/instances   200
POST   /api/v1/branches/{branch}/domains/{domain}/instance-maps/{fileName}/instances   201
GET    /api/v1/branches/{branch}/domains/{domain}/instance-maps/instances/{id}         200
PATCH  /api/v1/branches/{branch}/domains/{domain}/instance-maps/instances/{id}         200
DELETE /api/v1/branches/{branch}/domains/{domain}/instance-maps/instances/{id}         204

Three things that break naive ports:

• The by-id routes carry no {fileName}. Definition ids are globally unique, so the server finds the owning file itself.
• Update is PATCH, not PUT.
• The file must exist before you add definitions to it. Otherwise the add returns 404 with InstanceMapFile.NotFound. It returns 409 with InstanceMap.AlreadyExists when the id is taken anywhere in the domain.

Every route on this group requires authentication, and Pulse:Auth:Enabled=true is the shipped default. Send a Pulse bearer on every call. Commit authorship comes from the authenticated principal, defaulting to Anonymous.

Partial update and the typed clear#

On PATCH, an omitted field means keep it. That leaves no way to erase a collection, which is what clear is for:

{ "clear": ["source", "target"] }

Accepted tokens: "sources", "map", "properties", "label", "source", "target". id is not on the update body at all and cannot be changed. Sending {"properties": {}} is not an erase - an empty collection is indistinguishable from "unchanged" in the merge.

One commit for N definitions#

A batch is one unit of work: one validation of the whole domain and one commit, however many definitions it carries. fileName is set per item, so one call can populate definitions across every file at once.

Save, then compile#

Nothing you author exists as an instance until the domain is compiled.

PUT /api/v1/branches/{branch}/domains/{domain}/world

200 OK returns CompileResult { entityCount, edgeCount, archetypeCount, compiledAt, functionErrors[] }. There is no warnings member, and unresolved endpoints never appear here - they are validation violations (I-B6 / I-B7) raised before the commit. GET .../world reports isStale and compiledAtSha without recompiling.

Compilation is idempotent and not incremental: each call is a full recompile that replaces the cached world. Compile once after all definitions are in place, not between individual writes.

Compile aborts; it does not degrade. Error-severity violations produce 422 with a violations[] array and no world is built. It does not skip the offending definitions and build the rest.

Save and compile fail differently#

This is worth building into an import pipeline from the start.

A save that was valid all along runs in a throwaway worktree, fast-forwards the target branch, and leaves no session behind. So "you have a draft session" means "you have unpublished invalid work" - it is not the normal path for every write.

The pipeline contract:

1. POST or PATCH the definition.
2. Read the Atlas-Validation-Violations response header. It is absent on a clean save, not 0.
3. If it is present, GET /api/v1/branches/{branch}/domains/{domain}/validation for the rule ids, fix, and write again.
4. GET /api/v1/branches/{branch}/draft to check for a session; POST /api/v1/branches/{branch}/draft/publish to publish it. Publish merges the target branch into the draft on a scratch ref, re-validates the merged result across every domain and library, and fast-forwards the target only when that comes back clean. 409 with conflictFiles on a conflict, 409 when there is nothing to publish, 422 with violations[] when the merged result is invalid.
5. PUT .../world.

Restart behaviour#

Atlas recompiles every recorded branch and domain pair after it starts, in the background, without delaying the API. Domains flip to queryable one at a time as each recompile lands.

Loading many instances: templates, not singletons#

A pipeline that writes one Singleton definition per asset works, and it scales badly. Every definition is one request and one Git commit, so a site of 2,000 assets and 2,500 links is 4,500 requests and 4,500 commits, and the domain's history is 4,500 entries long. There is no bulk REST route to fall back on (see One commit for N definitions).

Write templates instead. One template definition expands into as many instances as it has rows or values, in one request and one commit. A site then comes down to about one definition per entity type and one per relationship type: tens of requests rather than thousands.

Prefer a source when the data lives in a table#

A RowsetTemplate is the better shape for anything you will load more than once. Point sources at a connector rowset, for example a SQL connector over a staging table your pipeline fills, and reference its columns as [source.Column] in instanceId, label and property values. Atlas reads the rows at compile and makes one instance per row. A re-sync is then "update the table, recompile": no per-item writes and no per-item commits. Free text is safe here, because each value arrives in its own column. See Building instances from a connector for the shape and the rules.

Lists in map when the data lives in your loader#

A StaticTemplate carries the values in the definition itself. Each map entry holds one comma list, the lists are read in parallel by position, and property values pick them up through placeholders:

{
  "id": "pumps-area-100",
  "name": "Area 100 pumps",
  "type": "urn:atlas:ontology:plant:Pump",
  "instanceId": "urn:atlas:instance:plant:[Tag]",
  "label": "[Tag]",
  "map": [
    { "name": "Tag",    "data": "P-101, P-102, P-103", "wrap": false },
    { "name": "Serial", "data": "SN4471, SN4472, SN4480", "wrap": false }
  ],
  "properties": {
    "urn:atlas:ontology:plant:SerialNumber": [
      { "type": "StaticStrategy", "value": "[Serial]" }
    ]
  }
}

Three pumps from one definition: P-101 with serial SN4471, P-102 with SN4472, P-103 with SN4480.

Rules a generator has to encode:

• Give every list the same length. Expansion is linear, not a cross product: position n of every list makes instance n, and a shorter list repeats its last value (or starts again, with wrap on). See Expansion is linear, not Cartesian.
• A value cannot contain a comma. There is no quoting or escaping; a comma always starts the next value.
• A list made entirely of ranges or multipliers is expanded. The whole data string is tried against the range and multiplier patterns before it is split (see The data grammar), so "100-102, 200-201" is five values, not two, and "Spare*2, Duty*1" is three. A list that mixes in anything else is split as literal text.
• Reference every variable. An unused one fails the save (I-A8).

That makes lists a good fit for identifiers, codes and numbers, and a poor one for names and descriptions. Put free text in a source, or set it per instance afterwards.

Relationships the same way#

A relationship definition is a template too: source and target take the same placeholders, so one definition makes every edge of a kind. With the pumps above and an area instance per pump:

{
  "id": "area-100-contains-pumps",
  "name": "Area 100 contains its pumps",
  "type": "urn:atlas:ontology:plant:AreaContainsPump",
  "instanceId": "urn:atlas:instance:plant:contains-[Tag]",
  "map": [
    { "name": "Tag", "data": "P-101, P-102, P-103", "wrap": false }
  ],
  "source": "urn:atlas:instance:plant:area-100",
  "target": "urn:atlas:instance:plant:[Tag]"
}

A relationship definition can carry sources as well, so parent and child identifiers can come from the same table as the items. See Relationships are their own instance maps.

Recommended build order for an import pipeline#

1. Create the type layer first. type, every property URI and every relationship archetype must already exist, or you will collect I-B1, I-B3 and I-B5 on the first save.
2. Create the instance-map files: POST .../instance-maps/ with { "name": "line-a" }. Stems collide case-insensitively.
3. Write entity definitions before relationship definitions, as templates rather than one singleton per item (see Loading many instances). Endpoints resolve against expanded instances, so a relationship written first dangles until its ends exist. Ordering does not affect the final result, but it keeps the violation list readable.
4. Write relationship definitions, using full instance URNs in source and target.
5. After every write, read Atlas-Validation-Violations. Do not proceed while it is present.
6. Publish the draft session if one exists.
7. PUT .../world once, at the end.
8. Read entityCount and edgeCount from the compile result and assert them against what you expected. Given linear expansion, an off-by-a-factor count is the fastest way to catch a map column you got wrong.

Complete worked example#

One file, three definitions: six cooling towers, two areas, and the six containment edges that connect them. Every field is one of the eleven accepted members; every strategy type is one of the six; the arithmetic is stated per definition.

[
  {
    "id": "plant-areas",
    "name": "Plant Areas",
    "type": "urn:atlas:ontology:plant:Area",
    "instanceId": "urn:atlas:instance:plant:area-[Area]",
    "label": "[Area] Area",
    "map": [
      { "name": "Area", "data": "North, South", "wrap": false }
    ]
  },
  {
    "id": "cooling-towers",
    "name": "Cooling Towers",
    "type": "urn:atlas:ontology:plant:CoolingTower",
    "instanceId": "urn:atlas:instance:plant:CT-[Area]-[Num, 00]",
    "label": "[Area] Cooling Tower [Num]",
    "description": "Three cooling towers per area",
    "map": [
      { "name": "Area", "data": "North*3, South*3", "wrap": false },
      { "name": "Num",  "data": "1, 2, 3, 1, 2, 3", "wrap": false }
    ],
    "properties": {
      "urn:atlas:ontology:plant:fanCount": [
        { "type": "StaticStrategy", "value": 4 }
      ],
      "urn:atlas:ontology:plant:supplyTemp": [
        { "type": "BoundStrategy",
          "bindingPath": "historian-plant/Utilities/CT-[Area]-[Num, 00]-TT01.PV" }
      ],
      "urn:atlas:ontology:plant:returnTemp": [
        { "type": "BoundStrategy",
          "bindingPath": "historian-plant/Utilities/CT-[Area]-[Num, 00]-TT02.PV" }
      ],
      "urn:atlas:ontology:plant:commissionedBy": [
        { "type": "NullStrategy" }
      ]
    }
  },
  {
    "id": "area-contains-ct",
    "name": "Area Contains Cooling Tower",
    "type": "urn:atlas:ontology:plant:AreaContainsCoolingTower",
    "instanceId": "urn:atlas:instance:plant:contains-CT-[Area]-[Num, 00]",
    "map": [
      { "name": "Area", "data": "North*3, South*3", "wrap": false },
      { "name": "Num",  "data": "1, 2, 3, 1, 2, 3", "wrap": false }
    ],
    "source": "urn:atlas:instance:plant:area-[Area]",
    "target": "urn:atlas:instance:plant:CT-[Area]-[Num, 00]",
    "properties": {
      "urn:atlas:ontology:plant:installDate": [
        { "type": "StaticStrategy", "value": "2026-01-15T00:00:00Z" }
      ]
    }
  }
]

What it produces:

A compile of this file reports entityCount: 8 and edgeCount: 6, assuming the ontology declares Area, CoolingTower, AreaContainsCoolingTower with matching endpoint constraints, and attaches fanCount, supplyTemp, returnTemp, commissionedBy and installDate to the right types.

Porting checklist#

Run this over any generator written before May 2026.

• [ ] Every route carries /api/v1/...; by-id routes have no {fileName}; update is PATCH.
• [ ] Every response is checked for Content-Type: application/json before parsing, so an SPA-shell 200 text/html from a dead route is caught.
• [ ] relationships[] is gone. Each edge is its own definition with a unique id, an instanceId, and full instance URNs in both source and target.
• [ ] No scheme:// appears in any bindingPath.
• [ ] Every placeholder is [Name]; no {i}, $name or ${name} survives.
• [ ] Every map column is materialised to the same length. Instance counts are asserted, not assumed.
• [ ] Every property key is a full urn:atlas:ontology: URI.
• [ ] Every strategy uses type with one of the six values.
• [ ] Every functionUri and propertyUri uses urn:atlas:ontology:, not urn:fn: or urn:atlas:prop:.
• [ ] Compile is PUT .../world, called once, and nothing reads a warnings field.
• [ ] Every write reads Atlas-Validation-Violations, and the pipeline publishes a draft session before compiling.
• [ ] No step assumes it must recompile after a restart.
• [ ] Every request sends a Pulse bearer; nothing sends X-Atlas-Author.

Related articles#

• Instance Maps
• Property Sourcing Strategies - Static, Bound, and Calculated - Static, Bound, and Calculated
• Atlas API Overview - Instance Maps
• Atlas API Overview
• Defining Types and Schemas
• Compiling and Publishing a Domain