The compliance team wants standing eyes on administrator activity in the appliance - logins, commands, configuration state - with zero ability to change anything. What is the correct provisioning design?

Compliance visibility is a provisioning decision the platform already anticipates: DD OS has no dedicated audit role, but its built-in user role can monitor the system and view status without any ability to change the configuration, and it is attached to individually named accounts for each compliance member. Named identities are the point: reviewers carry their own names while watching operators who hold no power over the reviewers' access. Because logs stored on the appliance can be affected by the very people under review, the practice pairs with scheduled export of the audit stream, for example to a remote log server, so review runs on evidence nobody in operations produces or curates. Handing out administrator accounts on the strength of a written promise fails by concept: a control that depends on restraint is not a control, and full rights remain whatever the paperwork says. Operator-generated summary reports fail by independence rather than content: evidence filtered through the reviewed team is not standing audit input. Riding on shared operator credentials erases the reviewers' own attribution - compliance becomes invisible noise inside the very trail they arrived to watch. Exam caveat: the security role is for security officers who authorize sensitive procedures, not for passive observers. Operational check: the compliance login views status and configuration successfully and is denied the first modification it attempts.