Jan,  Thank for the feedback. My use case is as follows: - Within the service create code, execute a dry-run (or some equivalent ) and end up with a fully modified set if configs for the devices in question. - Package the fully modified configs and feed them into a network modelling platform which will evaluate the new configuration changes (along with the rest of the unchanged network model) and predict what impact the modified configs will have to the overall network behaviour. - The result of the call to the modelling platform will be a binary pass/fail condition that will update a boolean "leaf" value in the service model. - I think I will have to leverage a kicker to have the service model initially execute, package up the dry-run information and send it to the modeling platform. - Once the modeling platform evaluates the changes, it will update the service vars to indicate pass/fail and my plan is to use that update to trigger a kicker for the service to "continue" ( I think this would be reactive Fastmap) or abort.   I'm working in python and I'm picking through the objects in root.devices.device looking for a way to retrieve a full-text representation of the config after the dry-run commit has happened but I haven't found it yet. In your response, you mention in option a.) I could produce some sort of output that represents the config with dry-run changes. If you could expand on that, I would appreciate it.   I suppose it would be possible within my service create code to pass the entire service model to some glue code that pulls the related device information from the production NSO/CDB and then recreates it in another "Sandbox" NSO system where it could do the commit, retrieve the entire config, then model everything. Once complete, the glue code would just delete the information from the sandbox NSO.   ... View more