The users! Provengo does not own, and cannot access these models. They are stored locally on user machines. Since Provengo runs locally, there's no dependency on our cloud or other such resources. The only expiation to this rule is the styling data for HTML reports, which normally sits on our servers to save space. Users can embed this styling info in the generated reports by using the --offline switch or the output.offline configuration key.
Using our test tools, of course. Provengo is a very good tool for testing software, and we say this from our own experience.
We have a Provengo model that contains various usage scenarios (specified using our state machine library). The scenarios are automated using our CLI library, which runs Provengo commands and then other command to validate the results. It's a multi-model approach, where one main model, which models user/CI behavior, interacts with sub-models, which represent the Provengo models used for system tests.
So basically we test Provengo by having Provengo run Provengo and other CLI tools for validation.
We made a video of this here.
We do. Provengo's DSLs are formally verified as part of our unit tests. The formal verification is done using Provengo's FM engine, and uses BP to specify requirements and violation conditions.
DSLs are notoriously tricky to get right, but we find that using this methodology we can eliminate corner cases, race conditions, and other menaces early in the design process, and define clearer semantics.