RedXaiHM 0.1 provides structural validation, atomic writes, lock files, backups, strict file extensions, and safe official editing paths. It does not yet provide encryption, signatures, access-control enforcement, or network authentication.

• Never store plaintext passwords. Store a password hash generated by the identity service with a modern password-hashing function and per-user salt.
• Do not store raw payment card data.
• API keys, OAuth secrets, mailbox credentials, recovery tokens, and session material must remain encrypted by the application until RedX Crypt is available.
• A value being omitted from global ID access does not make it secret; it only makes it local to the database structure.
• Language-extension restrictions on access points are descriptive policy and must be enforced by the service issuing SDK credentials.

The file store creates new database files and temporary files with owner-only mode 0600 on systems that honor POSIX permissions. Deployments should keep database directories outside public web roots and restrict the operating-system account that can read them.

RedX Crypt will use reviewed, standard authenticated-encryption and key-derivation primitives. RedXDevelopment may define its own envelope, key hierarchy, rotation policy, metadata, and developer experience, but will not invent an unreviewed cipher and represent it as secure.