# Same Model -\> Same Generated Runtime: Declarative Ignition Provisioning **URL:** \ **Category:** Ignition\ **Tags:** perspective\ **Created:** [April 28, 2026, 9:16pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289 "2026-04-28T21:16:19Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ates.turan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ates.turan/32/84773_2.png) [@ates.turan](https://forum.inductiveautomation.com/u/ates.turan)\ **Post date:** [April 28, 2026, 9:16pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/1 "2026-04-28T21:16:19Z")
Hello everyone, I have been exploring a simple question: Can an Ignition project be provisioned more like a repeatable software system and less like a manually assembled SCADA project? In short, I am trying to automate the building process itself, not just build another SCADA project (Platform as runtime). After following recent discussions around large-scale tag provisioning, version control limitations, and DevOps workflows in Ignition, I tried a different approach: treating the system as declarative state driven by a single definition. Over the last few months, I built an experimental (controlled deterministic lab) provisioning layer for Ignition called PHX IIoT. This is a single-developer concept validation, and the goal has been to treat Ignition as a runtime platform for declarative orchestration. I wanted to push that maturity logic one step further: "It works -\> It can be governed" -\> "It can be rebuilt from definition" From a single ISA-95-aligned CSV model, the current PoC generates: Tags and UDT instances Historian mapping and database schema Runtime UI structure in Perspective Core idea: The system is not the truth. The definition is. Currently validating practical limits under real-world conditions. In the current PoC, I can provision a live runtime from zero with roughly 30,000 tags in about 30 seconds in my test environment. What matters most to me is not only bulk generation, but determinism and repeatability: same input -\> same generated system -\> every time I have also been stress-testing the approach with controlled teardown / rebuild cycles and larger tag bursts to understand where the platform holds up and where instability begins. Demo video: [![](https://us1.discourse-cdn.com/inductiveautomation/original/3X/4/9/491d9ddd94a4ed5436c686746c4799df5f894f51.jpeg "PHX IIoT — Provisioning/runtime foundation for Ignition (Monolithic Structure PoC)") ](https://www.youtube.com/watch?v=BU7qWBIWs_4) Current environment: Ignition 8.3.2 Apple M1 Pro 2 GB JVM Observed so far: Deterministic rebuilds are working reliably in the current PoC. Observed performance: - Peak throughput: ~2,700 tags/sec - ~1k tags -\> 18.6 sec. - ~10k tags -\> 24.5 sec. - ~30k+ tags -\> 28.7 sec. (stability limits become visible after a few hours of runtime) - ~100k+ tags -\> ... (stability limits become visible during deployment) At roughly 35k tags, memory pressure and GC become visible and stability starts degrading. My current takeaway is that this kind of approach is most useful for template-heavy rollouts, standardized greenfield builds, and controlled brownfield rebuild scenarios. This is not a finished SCADA product. It is a provisioning/runtime foundation experiment. I would really value feedback from experienced Ignition users on a few points: 1. Does a declarative, repeatable provisioning model make practical sense for real Ignition projects? If you have seen similar model-driven rollout patterns, where do you think the biggest risks are? 2. During teardown / rebuild cycles, I sometimes see leftover tables or historian artifacts after a database wipe. Is there a reliable way to know when it is actually safe to begin a new deployment? I am also researching historian continuity parameters like UUID specially for disaster recovery situation. Notes on context: I pivoted into industrial software only a few months ago, so while I am pushing this hard from a software and systems perspective, I may still be missing some field-specific blind spots. That is part of why I am posting here. The goal is not control, write-back, or critical alarming, but safe onboarding of live field data into the model, followed by a limited reporting window to test whether the architecture remains useful outside a digital setup. My next steps after ensuring the final core (inc. hot-patching, fully decoupled architecture and safe historian continuity) are: - Validate the core in a real read-only shadow pilot - Improve communication and mapping layers - Build a limited public playground for teardown/rebuild testing I am still exploring the best path forward, so any feedback on ordering the roadmap would be incredibly helpful too. I am intentionally pushing beyond typical usage patterns to understand the platform, not to claim completeness or readiness. My goal is to make this layer safe and robust. So, brutal engineering feedback is very welcome. If you see where this breaks, I would genuinely like to know. If you break it, we are in this together. P.S. My name literally translates to 'Fire'. So I guess, ending up with Ignition was inevitable for me. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [April 28, 2026, 10:23pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/2 "2026-04-28T22:23:59Z")
In my opinion (as a fellow software first person with ~zero experience deploying Ignition in real systems), this suffers from a common category error: The actual fundamental problem is that real life drifts from computer systems moments after deployment. An immutable "deployed from base configuration" Kubernetes-like SCADA-as-cattle-not-pets layer sounds great, and (if everything in it works perfectly) eliminates one possible source of drift. It does nothing to address the **fundamental** tension - computer systems are not real life. As long as that's true (aka, forever) any digital system is always going to be working upstream. Today you write out a definition of your greenfield plant floor/facility/datacenter/whatever. You automagically create a SCADA system for it, and everything works perfectly. Tomorrow, a bird nests in a housing/a rat chews through a wire/a forklift drives through a wall/etc - some physical thing happens. Joe or Jane on the floor fixes it and moves on with their day. All **that** aside, > [@ates.turan](#): > > determinism and repeatability Just don't use LLMs, and you get determinism and repeatability for free. It's **harder** to make computers give you randomly wrong answers than it is to get them to give you the same answer every time. ---
**Author:** ![ates.turan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ates.turan/32/84773_2.png) [@ates.turan](https://forum.inductiveautomation.com/u/ates.turan)\ **Post date:** [April 28, 2026, 10:53pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/3 "2026-04-28T22:53:52Z")
Thanks for your comment Paul. I also appreciate the perspective, especially coming from a similar background. I think that concern is fair, but I may not have framed the scope clearly enough. I am not trying to solve physical-world drift. A bird nesting in a housing, a damaged cable, a technician moving something in the field, or an undocumented bypass will always exist outside the digital model unless someone captures that change back into the definition. I do not think a provisioning layer removes that reality. The narrower problem I am working on is configuration and runtime-foundation drift on the Ignition side: can tags, historian mappings, database structure, and generated runtime views be created, compared, torn down, and rebuilt from a single definition in a repeatable way? So for me, determinism here is not just “the computer gives the same answer twice”. In a stateful platform with async subsystems and side effects, the harder question is whether the observable deployed state is reproducible and reconcilable: same model -\> same generated runtime -\> same structural checksum / same deploy outcome That is the part I am testing. If the plant changes physically, the model must also change. I am not arguing against that. If anything, my assumption is the opposite: since reality will drift, the digital foundation should at least be explicit, rebuildable, and structurally comparable instead of partly living in manual gateway state. So I think your criticism is useful, but I would separate two layers: - Physical/operational drift in the plant - Configuration/runtime drift in the SCADA foundation (up-down scale or topology change) Nice point on determinism and LLMs. To borrow the contrast, what I am building is not a system that improvises. It is closer to a compiler plus a reconciler: the definition is the source of truth, the runtime is the materialized state, and reconciliation brings that runtime back in line when scale or topology changes. Put differently: the field will always be messy, but the map still needs to be clean. If the map is not clean, we cannot even observe or reason about drift in the field clearly. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 28, 2026, 11:10pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/4 "2026-04-28T23:10:54Z")
> [@ates.turan](#): > > reconciliation brings that runtime back in line when scale or topology changes I think this is the flaw. IMNSHO, reconciliation needs to update the definition to the found state of the runtime. The entire Ignition configuration and designer experience, and therefore the tools available for troubleshooting and issue resolution is **live**. Your idea of reconciliation destroys the answers to solved problems. Ideally, reconciliation would **report** the differences for evaluation, to see if **better** solutions can be offered in place of either simple definition change or runtime reversion to definition. ---
**Author:** ![ates.turan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ates.turan/32/84773_2.png) [@ates.turan](https://forum.inductiveautomation.com/u/ates.turan)\ **Post date:** [April 29, 2026, 12:02am UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/5 "2026-04-29T00:02:48Z")
Thanks, this is a very useful criticism. I think you are right that reconciliation gets dangerous if it means blindly forcing runtime back to the definition. In a live Ignition system, some runtime differences are noise, but some are the result of troubleshooting or hard-won operational fixes. In that sense, Joe and Jane (that Paul mentioned) are inside the system now: if they solve something live, the platform should detect it and force an explicit decision instead of silently deleting it. What I am converging toward now, especially for brownfields, is **governed** diff resolution. The definition remains the primary truth for generated foundation, but not every runtime delta should be silently overwritten. The flow is closer to "plan -\> review -\> resolve -\> apply". At that point, reproducibility is no longer just about the base CSV/model by itself. It becomes; "same base model + same resolution manifest + same policy set -\> same reconciled runtime". The shape I am imagining now is something like this: **Governed State Reconciliation** 1. A CSV/model arrives 2. The foundation reads the current runtime state 3. A diff is produced 4. The diff is classified into: - safe auto-apply - review required - dangerous/blocking 5. Only ambiguous conflicts are shown to the user 6. The user chooses one of a small set of typed outcomes: - revert to definition - promote runtime change back into the definition - keep as an explicit exception - defer 7. Those decisions are written into a resolution / override / exception manifest and journaled 8. Then the apply step runs 9. The final state is checksumed / verified again with governed state So the system would classify diffs first, only surface the ambiguous cases, and limit the outcomes to a small set: revert to definition, promote to definition, keep as exception, or defer. Those decisions would be written into a resolution or exception manifest before apply. Otherwise determinism is lost. Thanks, this discussion has been genuinely useful in sharpening the model for me. I think the more mature form of reconciliation in Ignition is not that definition wins no matter what, but a governed reconciliation process where the definition remains the primary truth, and approved exceptions are made explicit truth. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [April 29, 2026, 12:36am UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/6 "2026-04-29T00:36:01Z")
> [@ates.turan](#): > > is **governed** diff resolution This does sound interesting. Curious to see how it works out. ---
**Author:** ![ates.turan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ates.turan/32/84773_2.png) [@ates.turan](https://forum.inductiveautomation.com/u/ates.turan)\ **Post date:** [May 1, 2026, 5:33pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/7 "2026-05-01T17:33:22Z")
I made a short follow-up demo based on the feedback in this thread. [PHX IIoT - Rebuild Provisioning & Reconcilation Layer](https://youtu.be/VquVNYi_Z9U) The feedback changed the framing quite a bit. My first version was mostly: same model -\> same generated runtime But if live Designer/runtime changes sometimes need to be preserved, I think the safer model is closer to: same base model + same resolution/exception state + same policy set -\> same governed runtime So this became **less about provisioning** alone, and **more about authority modeling** : Who has authority over a difference? - the base definition - the live runtime - an operator decision - an approved exception - a blocking policy That is the main shift I took from the discussion above: **not source-only** authority, but **governed source/runtime** authority. Thanks to Paul and Phil for the pushback above. In the demo, I manually change a generated parent/child relationship in the Ignition runtime. The next deploy detects the drift, blocks automatic apply, and asks for an explicit decision: - REVERT\_TO\_DEFINITION - PROMOTE\_RUNTIME\_TO\_DEFINITION - KEEP\_AS\_EXCEPTION - DEFER I select KEEP\_AS\_EXCEPTION, and that exception becomes part of the governed state. The raw CSV stays the same, but the governed manifest/runtime CRC changes and verifies cleanly. So the updated idea **is not:** - CSV always wins. It **is:** - runtime-side changes should become explicit, reviewable, and journaled decisions before they affect the governed state. This is still synthetic lab behavior without real failure scenarios yet, but I wanted to validate the core reconciliation shape. Curious whether this “definition vs runtime vs approved exception” boundary makes sense for Ignition systems, and what production reconciliation cases I may still be missing. ---
**Author:** ![ates.turan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ates.turan/32/84773_2.png) [@ates.turan](https://forum.inductiveautomation.com/u/ates.turan)\ **Post date:** [May 11, 2026, 6:25pm UTC](https://forum.inductiveautomation.com/t/same-model-same-generated-runtime-declarative-ignition-provisioning/115289/8 "2026-05-11T18:25:52Z")
A short follow-up and thank you to the people who challenged the idea earlier in this thread. The discussion around reconciliation and real-world runtime drift helped me frame the project more carefully. In particular, it pushed the idea away from a simple “definition always wins” model and toward governed reconciliation: detecting drift, classifying it, and making the resolution explicit. Since then, I have started to see drift tracking and managed reconciliation as a separate layer of value for this kind of provisioning/runtime foundation — especially if the UI keeps operator workload low, reduces ambiguity, and makes decisions visible. I also submitted the project with more details to the Ignition Discover Gallery, mainly to get feedback. I framed it as an experimental runtime foundation, not a production-ready product, and mentioned this forum discussion as part of the development-by-feedback process. I’m attaching a future architecture direction I’ve been thinking through. It separates model-driven provisioning, runtime verification, drift classification, and governed reconciliation more clearly. I’ll follow up again if there is a field application, further validation, or meaningful architecture enhancement in the future. Thanks again to everyone who shared time, critique, and perspective here. It has been genuinely useful in shaping the direction, and I’m still open to comments, criticism, or perspective from the community at any level. ![Governed Reconciliation - Vision Phase](https://us1.discourse-cdn.com/inductiveautomation/original/3X/c/a/caf339f06e95464acfee40dcf39b63a6a75263c2.jpeg)