Permissions shape the interface
Roles, tenants, record access, and field visibility should be visible in the product surface before a build begins.
Security approach
Design the data boundaries before the interface ships.
CosmicDC treats security as part of the product surface: roles, permissions, sensitive fields, model context, exports, approvals, and handoff notes should be visible while the interface is still being shaped.
Boundary-first design
Complex interfaces need access rules built into the first draft.
Sensitive data stays explicit
PII, financial fields, internal notes, exports, and model-visible context are marked as constraints, not left as hidden assumptions.
Model context has boundaries
Prompts and generated screens should distinguish reusable product context from data that should be masked, summarized, or excluded.
Handoff includes the hard parts
Generated previews should carry notes about access rules, data ownership, integration edges, and open production questions.
Review questions
The safest interface is the one whose rules are easy to inspect.
This page is not a certification claim. It is the product standard we apply while shaping generated work into something a team can responsibly review.
Who can see this route?
Which fields are hidden, masked, or read-only?
What action requires approval?
What data can be exported?
What context can a model receive?
What should be logged for review?
Handoff clarity
Security notes should survive the prototype.
When an interface moves from preview to implementation, the sensitive parts should not disappear into memory or chat history. They should travel with the handoff.
boundary.handoff
Role and permission notes
Sensitive-field inventory
Workflow states and blocked paths
Model-context assumptions
Backend endpoint implications
Production gaps to resolve