The Designer Workspace produces three kinds of activity records, each with a different purpose. Knowing which one to look at — and which one a regulator will accept as evidence — matters for compliance.
Record | Purpose | Regulatory weight |
|---|---|---|
Recent Changes / Version Control (Designer → Track Changes) | Engineering-activity audit. Records who edited which object and when, with | Engineering activity log. The right place for "who changed the configuration" questions. |
MCP Category tag on objects | AI-authoring contract. Objects created by AI carry an | Authority record (which objects AI may modify), not an audit trail. |
| A trace file the Designer writes during AI sessions. Useful for troubleshooting an unexpected AI behavior — what tool was called, what arguments, what failed. Rotated per session into a | Debug aid only — NOT an audit trail. Customers requiring regulatory audit evidence must use Recent Changes / Version Control (engineering-time) or the runtime Alarm Historian via the AuditTrail toggles in Alarms Global Settings Reference (runtime control actions, including MCP Custom Tool execution). |
Designer authentication: Designer uses Windows Authentication. There is no plan to add OIDC, SAML, or any external IdP for Designer login. Operator-side IdP work (10.1.6) targets the Runtime HTML5 client, not Designer.
Compliance scope: FDA 21 CFR Part 11, NERC CIP-007, and IEC 62443 SR 6.1 regulate runtime control actions, not configuration-time engineering edits. The Designer Workspace is out of scope for those regimes; the runtime is in scope. See the relevant compliance how-to pages for the runtime audit-coverage matrix.