Standards applied through the work.

Protective behaviour is the shipped configuration. A user should not have to find an obscure setting before an application handles their data safely.

• Request only permissions required for the current capability.
• Keep secrets out of client code and source control.
• Treat storage, transport, logging and release configuration as security decisions.

Functionality earns inclusion by serving the person using the software. Product decisions should not create friction solely to increase engagement, capture data or obstruct an exit.

• Start with the user's workflow and expected outcome.
• Avoid dark patterns and artificial dependency on the product.
• Make destructive, paid or irreversible actions clear before they occur.

Necessary complexity is absorbed by the implementation. The interface should expose the decisions a person needs to make, while architecture and error handling manage the rest.

• Use platform conventions where they reduce explanation.
• Keep state and consequences visible at the point of action.
• Design useful behaviour for failure and recovery, not only success.

Every transfer and stored field should have a reason. Local and remote processing are distinguished clearly, and data is not treated as an incidental source of business value.

• Collect only what the product genuinely needs to operate.
• Separate local data from information that must reach a service.
• Consider retention and deletion while defining the data model.

When a choice benefits the business by misleading, pressuring or materially disadvantaging the user, it does not belong in the product.

• Describe capabilities and limitations accurately.
• Keep consent specific to the action being requested.
• Reject metrics that reward behaviour at the user's expense.

A released application remains the responsibility of the people who built it. Questions about behaviour, data handling and defects should reach someone able to investigate them.

• Provide a direct path for product and support enquiries.
• Investigate reported behaviour against real release conditions.
• Carry relevant findings into maintenance and future releases.