Skip to content
Merulan

Tags, policy, and field access

Tags, policy, and field access control which actions and values a caller may use in a Workspace.

Tags, policy, and field access set checks on data use. A Tag names a key and value. Governance & Administration owns its rules and grants.

Ownership

A Tag declares a key and its values in the Workspace's registry. Field Access grants a Member access to those values, either directly or through a Capability Bundle. A Purpose states the approved reason for use. In the Console, open /governance/tags, /governance/field-access, or /governance/purposes to inspect the named check. Policies at /governance/policies shows the active rules.

Lifecycle

A Tag value must be active before assignment. An object holds one value per key. Another assignment cannot silently replace it. Retiring a value blocks new use in authoring but preserves existing field gates and grants. A Purpose definition needs approval before use. Its policy decides whether each access request also needs approval.

A policy revision becomes active when publication succeeds. Publication keeps the written rule, active revision, and access checks in one change. If publication fails, the prior active revision remains in force. Read the policy validation contract before publishing a changed rule.

Boundaries

A Tag on an object does not grant access to it. The caller needs permission for the action and every grant required by the field. A missing required Purpose also masks the field. Field grants combine direct grants with inherited Bundle grants. Removing one grant leaves access intact if another Bundle still supplies it.

Data with a shared access envelope faces checks in a fixed order. The company and Workspace must match, then the Purpose, then every Tag grant. A denied read resolves no data source and never confirms that the data exists. Every envelope refusal reads the same to the caller.

Derived data keeps the company, the Workspace, Purpose, retention rule, and region of its input. It may add a Tag and may never drop one. Its derived status is permanent. A derived value can never become the authority for a later write. Use the original work's lineage to trace the input and its retained rules.

Failures

A Tag assignment is refused when the key or value is absent, retired, or already set on the object. A denied caller cannot use assignment to inspect the Tag registry. Retirement of an in-use value requires review of its affected fields. A masked field is an access result. It does not prove the stored value is empty.

Recovery

For a Tag refusal, inspect the active registry and the target object's current value before making another change. For hidden fields, check effective grants and the active Purpose. Review affected fields before retiring a value. Check that those fields still enforce their grants after the change. The Tag assignment contract owns the exact call and its errors.