Secure Development & Change Management Policy

1. Principle

Every change to production is made through version control, is reviewed by a person before it ships, carries no secrets, and can be reversed. The monitoring engine at the heart of the product is changed only deliberately and with its owner's explicit consent, never as a side effect of other work.

2. Source control

• All application code lives in a private GitHub repository owned by PsiCo, LLC. Production is built from its main branch.
• Every change is a commit with a message saying what changed and why. History is never rewritten on main.
• Secret material (environment files, Firebase service credentials, encryption keys) is excluded from the repository by its ignore rules and is never committed. Runtime data (turn records, logs) is likewise excluded.

3. Review before release

• The Founder reviews every change before it is committed to main, including changes drafted with the help of AI coding assistants, which are treated as proposals and not as approved code.
• Review checks that the change does what was intended, touches only the files it should, introduces no placeholder or dummy values, and does not alter the monitoring engine, its thresholds or calibration unless that was the explicit purpose.
• Changes to the engine, to authentication, to data retention, or to the public security statements require a deliberate decision recorded in the commit message.

4. Deployment

• Production is hosted on Render and deploys automatically from main; there is no manual copying of files to servers. The hosting configuration (start command, persistent disk, environment variable names) is itself kept in the repository.
• Configuration and secrets are supplied to the running service through the hosting provider's environment variables and secret files (SEC-02 §7). A change to a secret is a rotation, not a code change.
• Persistent data lives on a dedicated disk that survives deploys, so a release never destroys customer records or the engine's history.

5. Verification and rollback

• Significant changes are exercised against an isolated copy of the service before release, with any external services stood in for so the test never touches production data. Pages are checked as rendered, and access rules are checked for the three cases that matter: a stranger, a signed-in customer, and an administrator.
• After deploy, the change is confirmed live on the production site before the work is considered done.
• Because every release is a commit, rollback is a revert of that commit followed by the normal automatic deploy. Retention sweeps and data deletions are the only irreversible actions and are therefore scoped narrowly and logged.

6. Dependencies

• Third-party libraries are declared in a single requirements file with version constraints and are installed from the public package index at build time.
• Dependencies are updated deliberately, as their own change, and reviewed like any other; a security advisory affecting a dependency in use is handled under SEC-04.

7. Protecting the method

PsiGuard's monitoring engine is a trade secret. Development practice keeps it that way: internal signal names, thresholds and calculations appear only in server-side code; everything that crosses the wire or appears in a template, log sent to a third party, document or support reply uses the public vocabulary (Coherence, Memory Coupling, Drift, Entropy) and plain-language outcomes. Code review treats any leak of internal detail into a public surface as a defect to fix before release.

8. Environments and access

There is one production environment. Development happens on the Founder's workstation and in isolated, disposable workspaces that hold no production credentials. Nobody other than the Founder can push to the repository or change the hosting configuration (SEC-02 §6).