pl8ypus

pl8ypus / Applied AI Systems

Applied AI systems. Build evidence. Operating model.

Five production-shaped systems built for enterprise marketing operations, plus the build method and operating discipline behind them. Not demos - systems with real constraints, review controls, and deployment evidence.

View systems Build method

Greg's take

Most AI portfolio pages show demos. This one shows systems - or at least what I believe qualifies as a system rather than a demo: a workflow problem, a control layer, evidence of what it does, and a review step before anything is trusted.

The question I keep returning to is not what the model can do. It is what the human operator needs to see, understand, and decide before the output goes anywhere useful.

These five builds each expose a real workflow failure in enterprise marketing. The systems do not just automate. They make the automation reviewable.

Applied AI Systems

Build 01

Translation AI

Active build
Anthropic API Protected terms QA gate Human review GitHub versioning

Problem

Marketing translation done manually and inconsistently, with no protected-term enforcement, review trail, or version control.

System built

AI-assisted translation workflow with provider-agnostic orchestration, structured payloads, protected terminology, QA gates, and human review before outputs are final.

Why it matters

Proves repeatable AI workflow design with control layer, evidence capture, and review discipline - not just a prompt wrapper.

View Translation AI →

Build 02

Client Portal

Migration in progress
Cloudflare D1 Workers API Access/JWT Multi-client Request lifecycle Audit logging

Problem

Client support workflows managed across email, files, invoices, status updates, and memory - with no shared visibility, request tracking, or billing transparency.

System built

A real client operations portal for support requests, documentation, billing visibility, shared account access, admin controls, and Cloudflare-backed production migration. Built around Greg's real support and retainer workflow.

Why it matters

Proves Greg can build the operational layer around client work, not just AI demos. The kind of system that forward deployed engineers design inside real customer environments.

View Client Portal case study →

Build 03

Marketing Form Protection

Enterprise used
Cloudflare Turnstile Workers KV storage Eloqua API Multi-form

Problem

Enterprise form spam does not just create bad submissions. It pollutes Eloqua data, damages campaign reporting, wastes sales time, and creates operational noise across marketing automation workflows.

System built

Cloudflare Turnstile and Eloqua protection layer with exception queue, direct forwarding, accept/reject handling, secured reviewer access, and multi-form architecture. Applied to a real enterprise Eloqua marketing environment.

Why it matters

Proves Greg can build applied AI-adjacent workflow protection around real marketing operations, with anonymised enterprise usage evidence.

View Marketing Form Protection →

Build 04

Audience Finder AI

Active build
Cloudflare Worker KV memory Accept/reject Scoring model Export ready

Problem

Audience targeting decisions made without structured evidence, scoring criteria, or human review controls at scale.

System built

AI-supported targeting workflow with scoring, evidence trails, manual accept/reject controls, queue management, export readiness, and Cloudflare Worker backend with KV memory layer.

Why it matters

Demonstrates human-in-the-loop design with real backend infrastructure, not just a client-side scoring tool.

View Audience Finder AI →

Build 05

Tanya Build Cockpit

Operational
Structured prompts Project memory QA gates Agent roles Impl. packets

Problem

AI-assisted build sessions drift without structure, shared memory, or consistent QA checkpoints between sessions.

System built

AI-assisted build orchestration layer using structured prompts, project memory, implementation packets, QA gate patterns, and clear agent role separation. The operational scaffolding behind all other pl8ypus builds.

Why it matters

Shows the build discipline and AI collaboration layer that makes the other systems production-shaped rather than experimental one-offs.

View Tanya Build Cockpit →

Build method

Controlled delivery from problem to deployed system.

The pattern is consistent across every build. Workflow first. Architecture second. AI-assisted implementation third. QA, deployment, and evidence documentation throughout - not as an afterthought.

01

Discovery and workflow mapping

Understand the existing workflow, the people in it, and where AI changes the decision point. Map data flows and review steps before writing a line of code.

02

System architecture

Design the smallest complete system: inputs, outputs, data model, review layer, error paths, and deployment shape. Choose infrastructure based on the constraints, not the trend.

03

AI-assisted implementation

Build with structured prompts, project memory, implementation packets, and clear agent role separation. No unreviewed AI output goes directly to production.

04

Human review and QA

QA gates, acceptance criteria, test auth flows, and edge case verification before each slice is considered done. The build log records what was checked and what passed.

05

Controlled deployment

Deploy slice by slice with verification at each step. No big-bang releases. Rollback path is always clear and documented before deployment begins.

06

Evidence capture

Document what was built, what decisions were made, and what the system does at a level operators and stakeholders can trust and audit.

07

Repeatable patterns

Every build produces reusable scaffolding: prompt patterns, QA checklists, architecture templates, and deployment scripts. Each new system starts from a higher floor than the last - which means the delivery accelerates without sacrificing quality control.

Operating principles

What makes a build production-shaped.

The model is one part of the system

The model call matters. The control layer around it - inputs, validation, review, error handling, audit - matters more for enterprise deployment.

Human review stays visible

Every AI output layer has a human-readable review step. Operators should not need to trust the AI blindly.

Inputs are validated before AI runs

Bad inputs produce bad outputs. Source validation, structure checks, and completeness gates run before the model call.

Rollback is always possible

Working versions and approved versions are separate. Recovery from a bad deployment is documented before deployment happens.

Build evidence is public

Progress, decisions, and architecture are documented in the open. Stakeholders can follow the build without needing a briefing document.

Claim nothing before it is done

Status labels reflect actual build state: prototype, migration-ready, production-hardened. No system is called production before it is.

Want to discuss an applied AI project?

For enterprise AI systems, marketing automation, or workflow integration projects. Also available for speaking and demos.

About Greg