Techly Change Management Policy

Purpose

Most outages and many security failures start with a change. This policy sets out how Techly Operations Pty Ltd (Techly) changes Pyron so that every change is checked before it reaches customers and can be traced afterwards.

Scope

• Pyron's code, its configuration and its database structure.
• The infrastructure Pyron runs on: cloud resources, networks, access assignments, alerts.
• Techly's published documents: the legal pages, this Trust Centre and the website.

How a change is made

Every change to Pyron reaches production as a pull request into its production branch on GitHub.

• Required checks. A pull request merges only when the required checks pass: lint and static analysis (including security rules, secret detection and checks of infrastructure code), type checks, the test suites, a production build, a check that the published API has not changed incompatibly, and a scan that refuses any high or critical dependency advisory the change adds. The test suites run in CI, or on the author's machine with the result posted to the pull request. Everything else runs in CI.
• Tests with the change. A change carries the tests that prove it, and documentation that the change makes untrue is corrected in the same change.
• History kept. The production branch's history is linear and cannot be rewritten or deleted, so every change stays traceable to its pull request.
• Infrastructure as code. Cloud resources are defined in code. Each infrastructure change is merged first and then applied from the merged code, after a preview of exactly what will change has been read.
• Database changes. A change to the database's structure runs as a migration during the release, before any new code serves a request.

One engineer, and what makes up for it

Pyron is built and operated by one engineer, so a second engineer does not approve each change. Techly says so plainly. What stands in for that second person:

• the required checks above, which no change merges without;
• an AI code review of each change before it merges, a practice the engineer follows rather than a check GitHub enforces;
• the release trail: every production release is a recorded run tied to the change that triggered it;
• the activity records and alerts described in the Techly Information Security Policy.

The organisation's owner account can bypass the branch rules. That is kept for emergencies, and GitHub records each bypass.

Releasing

• Merging into the production branch releases to production automatically. There is no separate staging stage: the pull request's checks are the gate.
• A release does not start within 30 minutes either side of a customer's scheduled daily integration calls, and Techly does not merge or apply changes in the 45 minutes before one.
• After every release, automated checks confirm that the customer's scheduled integration still works and that no work is stuck. A failing check is treated as an incident.
• There is no rollback. A change that goes wrong is fixed by a new change, through the same checks.

Emergency changes

An emergency change, such as closing a security hole, still goes through a pull request and its checks. If those cannot run, the owner account's bypass may be used, and the change is reviewed afterwards, recorded as an incident, and its checks run once they can (Techly Incident Management Policy).

Changes to published documents

• The legal pages are issued as signed documents and generated from them, so a change is made in the signed document first.
• The Trust Centre and the website change through pull requests like any other change. Automated tests refuse the claims Techly has withdrawn, and hold the Trust Centre's statements on data locations and retention to the Privacy Statement's.
• Each policy and statement carries a version and an effective date, and every earlier version is kept in source history.
• The Website Terms are reviewed every year under this policy (their clause 34.4), and so is Techly's position on Amazon Bedrock (clause 23.2 of the Website Terms).

Who is responsible

• The Technical Director owns this policy, makes and releases changes, and applies infrastructure changes.
• Both directors approve changes to the legal documents.

Review

The Technical Director reviews this policy every year, and when the team grows enough for a second reviewer to be required.