# Integration — Where PDHPI Fits in a Cloud Pipeline

PDHPI sits alongside existing security infrastructure. It is not a
replacement for WAF, EDR, SIEM, or an IDS. It is a layer that adds
two specific things those tools usually lack: a rotating transport
wrapper, and an adversarial prediction loop.

## Where the two engines plug in

### Wrapper morph

The morph engine produces a current envelope (padding, framing, header
order). In production, that envelope is written to a config store that
the enforcement layer reads from:

- **AWS**: Parameter Store (SecureString) → Lambda@Edge or ALB listener rule
- **Cloudflare**: Workers KV → edge worker rewrites outgoing responses
- **Nginx**: a small Lua or JS module reads the envelope from Redis
- **Envoy**: a filter reads envelope config from xDS

### Prediction engine

The prediction engine runs as a sidecar or Lambda alongside the
application. It reads the same event stream that feeds the console,
maintains a short rolling window (10–30 events), and writes its
predictions to a queue:

- **AWS**: EventBridge → Lambda hypotheses → SQS prediction queue
- **Kubernetes**: sidecar container reads from a shared volume
- **Serverless**: Lambda runs on a 3-second schedule

Standing predictions are consumed by the WAF layer as **pre-armed
rules**. When an event matches a prediction, the WAF acts immediately
without waiting for the next scoring cycle.

## What fits

- **WAF + CDN** — reads access logs, updates IP sets, consumes predictions
- **Application log pipelines** — CloudWatch, Loki, Splunk, Datadog
- **Container platforms** — sidecar or standalone service
- **Existing SIEM** — predictions and morph log feed in as signals

## What does not fit

- **Endpoint agents (EDR)** — the console is network-facing
- **Identity providers** — the console consumes identity signals, does not issue them
- **Legacy SIEM-only stacks on 15-minute batch windows** — the console operates in milliseconds and seconds

## Deployment shapes

### Shape A: Elastic Beanstalk

Fastest path. Upload the zip, Beanstalk provisions PHP on EC2 behind an
ALB. State lives on disk. Single-instance mode is sufficient for demos.

### Shape B: ECS Fargate

Containerize, push to ECR, run on Fargate. State must move to DynamoDB
or ElastiCache. This is the production-correct shape.

### Shape C: Lambda + Bref

Serverless PHP. State moves to DynamoDB or S3. Prediction engine can
run as a separate scheduled Lambda.

## What we deliver in an engagement

1. **Assessment** — current stack, where each engine plugs in
2. **Deployment** — console running in the client environment
3. **Calibration** — prediction models tuned to real traffic
4. **Integration** — wrapper config flowing to the edge, predictions to the WAF
5. **Handover** — docs, training, support