Output is not product shape.
Karri Saarinen argues that good software carries the perspective of its makers. He describes that perspective as learned judgment. It comes from using the product, speaking with customers, making mistakes, and deciding what deserves attention.[1]
His warning lands hard in an agent-heavy workflow. Independent changes can each look reasonable while the product turns into a list of capabilities. More code passes. The whole becomes harder to recognize.
The missing control is not another generator. It is a person who can say, "This works, and it still does not belong."
Write down the shape before protecting it.
A product point of view needs concrete handles. Record the user problem, the behavior worth preserving, the tradeoff you accept, and the capabilities you will not add. Link those decisions to the code paths they govern.
This is not a substitute for user research. It is a way to keep the result of that research from dissolving across many small changes. A decision record should name who made the call, what evidence they used, and what would reopen it.
Code ownership is a routing rule.
GitHub's CODEOWNERS file can assign people or teams to repository paths. GitHub can request those owners when a pull request changes their files. A protected branch can also require code-owner approval.[2]
That machinery routes a review. It does not prove the named person has time, product context, or authority to reject a locally sensible change. Test the route. Open a draft, mark it ready, confirm the right owner is requested, and record who covers an absence.
Presence includes the exit plan.
GitHub lets a personal account name a successor who can manage user-owned repositories if the owner cannot. The invitation remains pending until the successor accepts it.[3]
That setting handles repository custody. A real handoff also needs release credentials, build instructions, service ownership, support routes, and a current decision record. If the next maintainer can clone the code but cannot ship or explain it, custody did not transfer.
Provenance and people answer different questions.
SLSA separates source integrity, build integrity, and availability. Its availability definition includes keeping the package buildable and maintainable, with code and change history available for investigation and incident response.[4]
Provenance can show which source and process produced an artifact. It cannot tell you whether the product still has a coherent point of view. Keep both records. One protects the artifact chain. The other protects the decisions that make the software worth maintaining.
Run a presence check.
- Find the current product decision record and one explicit non-goal.
- Change a representative path and confirm the intended owner receives the review request.
- Send a harmless test through the public support or security route and verify it reaches a maintained queue.
- Ask a second person to build a release and explain one hard product decision without private rescue.
The switchboard below drafts the missing fields. Selecting a circuit does not prove that the route works.