Technical decisions should reduce risk

1. Complexity follows risk

   We define the business outcome and material constraints first, then choose the smallest sufficient architecture.

   Risk

   A project receives either a fragile shortcut or an expensive architecture built for a future that may never arrive.

   Decision

   We assess the product's role, data, access, consequences of failure, and operating cost. A new layer is added only when it closes a specific risk.

   Client outcome

   The client pays for complexity that protects the outcome, not for technical ambition without practical return.

2. A change must be verifiable and reversible

   Critical changes pass checks and have a clear recovery path before they reach production.

   Risk

   A manual change turns production into an experiment, while recovery is discovered only after a failure.

   Decision

   We use automated checks, immutable builds, checksums, atomic releases, and rollback where the cost of failure justifies them.

   Client outcome

   A release becomes a controlled event that can be verified, identified unambiguously, and reversed safely.

3. The system limits authority

   Access for a person, service, or AI is shaped by the data involved and the acceptable consequences of error.

   Risk

   Excessive access turns an ordinary user, integration, or model error into a system-wide incident.

   Decision

   We separate environments and secrets, set explicit access boundaries, and keep costly or irreversible actions subject to human approval.

   Client outcome

   Even when something fails, the blast radius stays contained and a critical decision never depends on an interface or prompt alone.

4. The result must survive handover

   Structure, instructions, and operating decisions should remain understandable after development ends.

   Risk

   When knowledge lives only with the developer, every change, recovery, or handover becomes a new project.

   Decision

   We document system boundaries, checks, release, and recovery, adding observability only where a material failure would otherwise remain invisible.

   Client outcome

   The product can be maintained and developed without permanent dependence on one person's memory or hidden ownership cost.

Where these decisions are implemented

1. Still Stage

   Risk of data loss during application replacement → a separate persistent database → product state stays outside the replaceable container.

2. DoMiSoul

   Risk of losing an enquiry during a release or mail failure → separate enquiry storage and a notification queue → storage remains independent of email delivery.

3. AgentDesk

   Risk of executing an incorrect AI suggestion → read-only sources and owner decisions → automated analysis does not authorize sending mail or trading.