Every promotion in your Anaplan landscape, where it came from, where it went, and what authorized it.
A promotion path of the kind common in a multi-entity landscape. A shared development environment feeding several test environments, each feeding its own production environment, with a version targeted across all of them.
Every line is a promotion, or a deployment if that is the term your team uses. Every promotion is a point where authorization either exists and is attached to the change, or exists somewhere else, or does not exist.
An organization running eight or twelve governed models across four environments is managing dozens of promotions per release cycle. Each one needs its own authorization, its own testing evidence, and its own confirmation of result.
Where that checking is done by people, it is done once per promotion, not once per release. That is where the effort goes, and it is why the record has to be reconstructed later rather than retrieved.
A promotion here is not a movement of metadata with a timestamp on it. Each one arrives with the things that make it answerable later.
A year later, the question of what this line was and who allowed it is a retrieval.
The approval exists before the change and travels with it.
Changes that arrived another way are identified within minutes and put in front of someone who can determine whether they were intended.
The running state is compared against the approved baseline, and the comparison leaves its own record.
Was What's Running Approved?
Why the authorization and the approved state have to sit outside the platform they describe, what conventional software architecture settled on over three decades, and what that means for an Anaplan landscape under audit.
Read the paper