# Scaling Check

<details>
<summary>What is the recommended overall approach to scaling a Kanoa implementation?</summary>

Build a good reference implementation for an asset type first, then reuse it with import/export, asset duplication, or scripts, and review and adjust whatever must be unique for each copy (name, tag paths, ERP name, schedule settings, and so on). Scale a validated pattern rather than copying incomplete configuration. See [Scaling Across the Enterprise](../07-scaling-across-the-enterprise/index.md).

</details>

<details>
<summary>You need to migrate an existing asset hierarchy from another system. What approach does the course recommend?</summary>

Export the hierarchy to a flat file, convert it into Kanoa's asset export JSON structure (using an existing asset export file as the template, for example with AI), and import the file on **Configuration → Ops → Assets**. The more you export (assets, items, states, modes, links), the more you can import. See [Create Assets with Scripting](../07-scaling-across-the-enterprise/1-script-assets.md).

</details>

<details>
<summary>How does the rollout script decide which asset to copy, and why does that depend on asset groups?</summary>

It looks up the assets in the `Machines` asset group and copies the first one returned (`Machine 1`) with `system.kanoa.asset.copyAsset`. Asset groups let a script find a template for a type of asset without hard-coding an asset ID. See [Create Assets with Scripting](../07-scaling-across-the-enterprise/1-script-assets.md).

</details>

<details>
<summary>What does system.kanoa.asset.copyAsset copy?</summary>

An identical copy of the asset, including its child assets and its links to modes, states, items, and attributes. See [Create Assets with Scripting](../07-scaling-across-the-enterprise/1-script-assets.md) and [copyAsset](../../../systemFunctions/asset/copyAsset.md).

</details>

<details>
<summary>After copying Machine 1, why does the rollout script still write to tags in Ignition?</summary>

Copying the asset doesn't connect the new asset to its own equipment data. The script writes each new asset's MQTT path parameter (`Line/Parameters.MQTTPath` under the asset's tag path) to its matching `[Kanoa]CoreForge Sim/Site/Machining/Machine N/assetInputs` path. Without that, the copy would not read its own simulator tags. See [Create Assets with Scripting](../07-scaling-across-the-enterprise/1-script-assets.md).

</details>

<details>
<summary>The item rate script stops with a KeyError on 'boxes'. What is the likely cause?</summary>

The script looks up unit IDs by name, and the `boxes` unit doesn't exist (or isn't enabled). It is used as the outfeed unit for `Manual Pack 1`, and you create it in Configure Production Rates. See [Create Items with Scripting](../07-scaling-across-the-enterprise/3-script-items-and-rates.md).

</details>

<details>
<summary>Why is the system.kanoa API preferred over direct SQL for bulk configuration?</summary>

It follows Kanoa's data model, executes application logic consistently, reduces the risk of missing related records, and uses supported functions that behave the way the product itself does. See [Create Assets with Scripting](../07-scaling-across-the-enterprise/1-script-assets.md).

</details>

<details>
<summary>In what order must downtime configuration be created, and where is the state code assigned?</summary>

State categories must exist before states can be created in them, and states must exist before they can be linked to assets. The state code is assigned on the asset-state link, by `system.kanoa.asset.linkAssetStates`, not on the state itself. See [Create States with Scripting](../07-scaling-across-the-enterprise/2-script-states.md).

</details>

<details>
<summary>How does the generateStates script avoid assigning a state code that is already in use on the asset?</summary>

It reads the states already linked to the asset, takes the highest existing state code, and numbers the new links from the next value up. If the asset has no linked states, it starts at 1. See [Create States with Scripting](../07-scaling-across-the-enterprise/2-script-states.md).

</details>

<details>
<summary>Why do the scripts look up IDs by name or path instead of hard-coding them?</summary>

Database IDs may differ between development, test, and production systems. Names and paths, like `CoreForge\Philadelphia\Machining\Machine 1`, are more portable, so the same script works on any gateway that has the same configuration. See [Create States with Scripting](../07-scaling-across-the-enterprise/2-script-states.md).

</details>