How AI Decisions and Business Controls Are Managed
Several of the systems in this portfolio touch email delivery, publicly published contact data, automated decisions and AI agents working against a live system. That makes these controls part of the product rather than a policy added afterwards.
Designed to support responsible operation through human approval on high-impact actions, unsubscribe and bounce controls, audit trails, and clearly defined limits on what automation may decide.
This page describes controls that exist. Where something is designed but not yet switched on, it is labeled that way here and on the case study — and the capability inventory states the current state of every capability on the platform.
The principle
Where the line sits
I use AI to improve analysis, recommendations and productivity, while keeping approvals, permissions and critical business rules inside reliable software workflows. High-impact actions require a person to approve them.
Where exactly that line falls is a decision made per project, and each case study states the boundary it actually uses.
The 24 controls below are grouped by the area they protect. Each one exists because of a specific failure it prevents, and each links to the case study that describes the mechanism.
6 controls
Email delivery and campaign operations
The rules here are the ones with the highest cost of being wrong, so they are enforced structurally rather than documented and trusted.
Suppression consulted before every handoff
Every send path passes through one mandatory filter. Suppressed recipients are removed before anything downstream sees them — the delivery engine is never relied on to reject them.
Suppression is append-only in production
No bulk deletion and no truncation. Removing someone from a suppression list is the one operation that can silently re-permission a person who asked not to be contacted.
Unsubscribe mechanism on every outbound marketing message
Applied during message generation rather than left to a template author to remember.
Bounce and complaint processing must always be running
Its absence is treated as a failure with its own liveness check, because a stopped processor produces a suppression list that stops growing — which looks exactly like a quiet week.
Autonomous delivery protection
Delivery health rules evaluate on a fixed cycle and can throttle or pause a campaign without waiting for a person to notice a problem.
Reporting states its own boundary
The blocklist reputation view carries a line on the page itself: it reports, it never blocks a send. A tool that silently changes sending behavior is a different tool from one that informs a decision.
6 controls
Lead discovery and public data
Discovery finds publicly published business contact information. The design question is not whether it can be automated end to end — it can — but whether it should be.
No automatic path from discovery into sending
There is no code path from a discovery result to a sending list. An operator reviews filtered results and explicitly creates the list. A confidence threshold was considered and rejected: a threshold is a number someone raises under deadline pressure.
Publicly published business information only
No scraping behind authentication. Stated as an explicit non-goal of the service, not as an implementation detail.
Provenance is reconstructable
Query generation is reproducible, and every list records the job it came from — so the question 'where did this list come from?' has an answer months later.
Validation before use, not after sending
Mail-exchange validity, role-address classification and suppression status are checked and shown to the reviewer, rather than discovered from bounces after a campaign.
Enrichment cannot block or gate sending
Background-only, with every consumer required to tolerate a missing record. An external data source is never allowed to become a dependency of the send path.
Egress classified before it is permitted
Requests through the proxy pool are classified before connection, and financial, payment, checkout and login destinations are refused outright, with per-feature kill switches and an audit trail.
8 controls
AI agents and automated decisions
An agent that can act on a production system is a contractor with credentials. The controls are the ones you would apply to a contractor.
Human approval on every production change
No model applies a change to a production system. Diagnosis runs read-only until a person approves the action — a rule with no threshold, because a threshold requires judgment exactly when judgment is under pressure.
Confirm-before-execute for assistant actions
When the in-platform assistant decides to act, it writes a pending row and stops. A human confirms, and only then does the action execute. Every run is auditable across the whole fleet rather than only inside one conversation.
Fail-closed capability checks
An action against an unreachable capability registry is denied, not allowed. An outage cannot become an authorization bypass.
Staged rollout per capability
Every capability starts in observe mode. Moving to assisting, and then to acting on production, is a deliberate per-capability decision rather than a global default.
Bounded cost and runtime
Every agent job runs under an explicit token, tool-call and runtime ceiling, so a runaway loop is bounded by construction rather than by someone watching a bill.
Deterministic gates with no model in the loop
Formatting, linting, type checking, secret scanning and schema validation run mechanically on every commit. A gate has to give the same answer every time, which rules out asking a model.
Decisions are explainable after the fact
A decision can be stored with its reasoning, the signals used, a confidence breakdown and the alternatives considered — so an automated decision can be reviewed rather than only observed.
A human owns every client commitment
In the agency operating system, AI handles acknowledgment, qualification, drafting and creative production. Anything that commits the business to a client passes through a person first.
4 controls
Data handling and access
Most of these are boring. Boring is the point.
Credentials encrypted at rest, never displayed
Model provider keys are held encrypted with only a last-four fragment retained for identification, against an allow-list of providers.
Role-based access and per-agent keys
Agent identities carry their own signing keys that can be minted and revoked independently, with a global kill switch above them.
Isolation by process, not by configuration
The public tracking surface runs as a separate process containing only tracking routes. An allow-list rule is one edit away from exposing an administrative API; a process that does not contain those routes cannot.
Data minimization in what gets published
No recipient data, client identity, campaign volume or infrastructure detail appears in these case studies. Several screenshots were withheld entirely rather than redacted into meaninglessness.
This site
What this portfolio does, since it is also a published system
- No tracking, no cookies, no third-party scripts
- This site is static files. It sets no cookies, loads no third-party resources and collects no personal data. Fonts are self-hosted so the browser makes no external request.
- Every project states an honest status
- Including the uncomfortable ones — partially operational, built but dormant, declared but not wired. The capability inventory labels the runtime state of every capability rather than implying everything runs.
- Missing evidence is shown as missing
- Where a screenshot or a figure does not exist, the page says so in place rather than filling the space with something plausible.
- Every published figure names its source
- Self-reported figures are labeled self-reported. Enterprise figures are stated as program facts rather than as personal results.
- Sanitization is mechanical, then manual
- A deterministic scan blocks credentials, addresses, internal hostnames and client identifiers from the repository. It cannot check pixels, so every screenshot is also reviewed at full resolution before publication.
Limits
What is not being claimed
- No claim of legal or regulatory compliance is made here. Compliance is a determination made against a specific jurisdiction and a specific set of facts; these are engineering controls designed to support it.
- These controls describe systems I own. They are not a template, and the right boundary differs by product, data and jurisdiction.
- Where a control is designed but not yet wired in, that is stated on the case study and in the capability inventory rather than implied to be running.
Happy to go deeper on any of this
Including the controls that were considered and rejected, and why.