An auditor asks who approved the production change on 14 March and the answer is a Slack thread. Here is the model behind a change log, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A change request log needs four things: a change record with a risk classification, an approval path proportionate to that risk, a rollback plan captured before the change rather than during the incident, and a link between changes and incidents. The design constraint is that a heavy process gets bypassed. Classify most changes as standard and pre-approved, so the process applies its weight only where it earns it, and the log stays complete because complying with it is cheap.
Change log
48
Changes this month
41
Standard, pre-approved
2.1%
Followed by an incident
1
Type to reclassify
Change calendar, by system
You run engineering or operations, and something asks you to evidence change control: an audit, a customer questionnaire, or a bad month. What you want is a log that is complete because it is easy to comply with.
What filing a change looks like when the process is light enough that people actually do it.
Filed in under a minute, no approver. If filing is slow the log will be incomplete and nothing else here matters.
A short questionnaire about data, reversibility, downtime and history produces the level, which removes both guesswork and the incentive to under-rate.
Standard needs none, normal goes to the system owner, high risk adds a second approver.
Implement first, file within a window, review retrospectively. A process with no emergency path just loses the record.
Steps, expected time, and the signal that would trigger it.
Change-related incident rate by type is what tells you whether the classification is calibrated.
A change log is not a ticket per deploy. It is four parts, and the first one determines whether anyone uses it.
What is changing, to which systems, when, by whom, and a risk classification. Standard, normal and emergency, with the criteria for each written down.
Standard changes pre-approved by their type. Normal changes approved by a system owner. Emergency changes fast-tracked and reviewed afterwards.
How to undo it, how long that takes, and how you will know it is needed. Captured before the change, because during an incident it will not be.
Changes referenced from incidents and incidents visible from changes, producing a change-related incident rate that tells you whether the process helps.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Classification derived from questions, not from self-assessment.
In this Helix project, build me a change request log.
The design constraint that beats everything else: filing a routine change
has to take under a minute. A heavy process gets bypassed, and a bypassed
log is worse than no log because it looks complete.
So define standard change types in a config file: the routine things like a
dependency bump, a config value inside a known range, a scheduled restart,
a documented data fix. Each says which systems it applies to and that it
is pre-approved.
For everything else, derive the risk level from a short questionnaire
rather than asking someone to pick one. Does it touch customer data. Is it
reversible. Does it need downtime. Has this type of change caused an
incident before. Deriving it removes the guesswork and the incentive to
under-rate.
Record: title, description, systems affected, type, risk, requester,
implementer, planned and actual windows, related ticket or pull request,
and outcome.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Weight where it is earned, and an emergency path people cannot skip.
Standard changes are pre-approved by type. Log them anyway, with no
approver. The log has to be complete to be worth anything.
Normal changes route to the owner of each affected system, with a second
approver above a risk threshold I set.
Emergency changes get implemented first, filed within a window I
configure, then reviewed retrospectively by a named reviewer. Build that
path deliberately. A process with no emergency route does not stop
emergency changes, it just loses the record of them.
Show approvers what is changing, the risk answers, the rollback plan, the
window, and any incidents previously linked to this system or change type.
Deputies for every approver with automatic reroute, because a change
waiting on somebody who is away is a change that happens without a
record.And record what actually happened, not just what was approved.
Require a rollback plan on every non-standard change: the steps, how long
it should take, and the signal that would trigger it. Writing that during
an incident is when it is least likely to be right, and the person
responding may not be the person who made the change.
Require a verification plan too: how the implementer will confirm it
worked, and over what period.
On execution, record the actual window and the outcome from a fixed list:
successful, successful with issues, rolled back, failed. Anything other
than successful needs a short explanation and a note of whether an
incident was raised.
Add a change calendar by system and window, with a warning when two
changes touch the same system at the same time. And optional freeze
periods, with an override that requires a reason.Worth knowing. Recording the actual outcome, not just the approval, is what turns this from a compliance artefact into an operational one.
Linking changes to incidents, and the finding that follows.
Let me link a change to an incident from either side, with a relationship
type: caused, contributed to, or discovered during.
Then report change-related incident rate: the proportion of changes
followed by a linked incident, broken down by type, risk level and system.
Plus rollback rate, failed change rate, and time from request to approval
by risk level, since slow approval is the leading cause of an incomplete
log.
Build the audit export: every change in a period with its classification,
its approvals and timestamps, its outcome, and any linked incidents. One
click, because that is what the log is for.
And flag any change type classified as standard that has a higher incident
rate than normal changes. Those are misclassified, and the data will tell
you before an auditor does.Worth knowing. A standard change type with an elevated incident rate is the most useful finding this app produces, and it needs nothing you are not already recording.
The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<GitHub>. Read what actually shipped and when, so a standard change is one
confirmation rather than a form.
<Jira>. Link a change to the work behind it and to any incident that
followed.
<Datadog>. Correlate changes with incidents, which is how you find a
misclassified standard change.
<Slack>. Route approvals for the changes that genuinely need one, and
reroute to a deputy.
<ServiceNow>. If change management already lives here, read and write
there rather than running two logs.
<LaunchDarkly>. Read flag changes, which are changes to production whether
or not anybody filed one.
<Okta>. Attribute every filing, approval and skip to a verified person,
which is what makes it evidence.
<Snowflake>. Join the change log to the incident record, which is what
makes change-related failure rate a number rather than an argument.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. This log is the evidence you hand an auditor, so entries have to be reliably attributable. Set Access Control before sharing.
The log is only complete if filing is nearly free, which means reading most of it automatically.
GitHub
Read what actually shipped and when, so a standard change is one confirmation rather than a form.
Jira
Link a change to the work behind it and to any incident that followed.
Datadog
Correlate changes with incidents, which is how you find a misclassified standard change.
Slack
Route approvals for the changes that genuinely need one, and reroute to a deputy.
ServiceNow
If change management already lives here, read and write there rather than running two logs.
LaunchDarkly
Read flag changes, which are changes to production whether or not anybody filed one.
Okta
Attribute every filing, approval and skip to a verified person, which is what makes it evidence.
Snowflake
Join the change log to the incident record, which is what makes change-related failure rate a number rather than an argument.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working log. It is the evidence you hand to an auditor and the record you read after an outage, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
A change log is only evidence if entries can be attributed reliably. SSO means every record carries a verified identity rather than a typed name.
App Security
Linking changes to deploys, tickets and monitoring needs real access to those systems. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
A record of every change made to production systems, with a risk classification, an approval proportionate to that risk, a rollback plan, and the actual outcome. It is both an operational tool and the evidence an audit asks for.
Classify most changes as standard and pre-approved by type, so they are logged in under a minute with no approver. Reserve real approval for changes that are irreversible, touch customer data, or come from a type that has caused incidents before.
With a defined fast path: implement first, file within a set window, then review retrospectively with a named reviewer. A process with no emergency path just means emergency changes go unrecorded, which is the worst of both outcomes.
Because during an incident is exactly when nobody has time to design one, and when the person who understands the change may not be the person responding. Writing the steps, the expected time, and the trigger signal beforehand costs a few minutes.
Change-related incident rate, broken down by change type and risk level. If standard pre-approved changes show a higher incident rate than normal ones, the classification is wrong, and the data says so before an auditor does.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build. The judgement calls are which change types are standard and where the approval thresholds sit.
IT and Operations
Record incidents with a consistent timeline, run postmortems to a fixed template, and track the action items until they are actually done. Prompts to build it, and what it takes to run it.
Product and Engineering
Generate the right checks for the kind of release it is, block on the ones that matter, and tell the teams who need to know before it ships. Prompts to build it, and what it takes to run it.
IT and Operations
Request access against a defined catalogue, route it to the system owner, grant it with an expiry, and produce the evidence an access review needs. Prompts to build it, and what it takes to run it.
Legal and Compliance
Tier vendors by the risk they actually carry, ask each tier only what it warrants, track findings to closure, and re-review on a schedule. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.