From a process point of view, the netYCE framework is set up in such a way that you (can) first prepare changes before you deploy anything into production and that what gets Built (prepared) is fully compliant with your design. So you prepare your intended state of the network, based on your design rules and then deploy it to production with automatic validation. All this is done by combining the three layers within netYCE: ‘Design’, ‘Build’, ‘Operate’.
The ‘Build‘ layer lets you prepare any type of change. You then use the ‘Operate‘ tools to deploy your intended changes to production. Within the ‘Operate’ tools, you (can) then use ‘scenarios’ (to be used in combination with each job) to validate production settings as these might be different to what you expect. So to guarantee that nothing gets broken in production, the scenarios let you define how to automatically roll-back when some criteria are not met.
To guarantee that whatever gets built within the netYCE database is based on your (high- and low-level) design rules, you (can) use the ‘Design‘ tools. Here’s you set the rules to auto-populate parameters (e.g. handing out IP addresses or VLAN numbers) and automate any sequential number of engineering steps that you could also do through the GUI (or API).
To guarantee ‘As Designed = As Deployed’, these 3 layers are used in combination, whereby the ‘Design’ set-up is typically configured once for each network.
Also, these layers can be used separately. So just use the ‘Operate’ or ‘Build’ tools. This all depends on your use desired case, experience and/or maturity level as an organisation.