Going live

The safe path to production is the same for every tenant type: integrate, run in shadow to build your Shadow AOP Ledger, calibrate your AOPs against it, then switch to enforcement. This page is the checklist. It is the AOP lifecycle applied: observe, capture, author, enforce.

Shadow first, always

Shadow mode computes every decision and records it to your Shadow AOP Ledger, but does not block anything. It is the difference between trusting the engine and fearing it. In shadow you run your full integration against live traffic and see exactly what enforcement will do, with zero risk to a customer or a system.

While in shadow, the data plane still returns the real verdict, marked as shadow, so your code can log what would have happened without withholding anything.

Calibrate your AOPs from the ledger

Read the Shadow AOP Ledger in the audit view. For each thing the engine would have blocked or held, ask whether you actually wanted that, and adjust the AOP until the answer is yes.

• If it would block something legitimate, loosen or correct the AOP, the catalog, or the claim list.
• If it would let through something you care about, tighten the AOP or add the missing entry.
• Give it enough days to see your real range of traffic, not just the easy cases.

Promote to enforcement

When the ledger shows the engine would decide the way you want, turn enforcement on for the tenant. This is the promotion step of the lifecycle: the AOPs you validated in shadow now act. A deny stops the action or response for real, and a hold waits for a human. A practical pattern is to enforce the hard limits you are sure about and keep the fuzzier judgment calls in shadow a little longer.

Set your caps before traffic grows

• Input gate daily cap and response model daily cap protect you from runaway model cost. Set them to sane values for your expected volume. Over the cap, the model work is skipped and the check fails open.
• Rate limit protects the tenant from a runaway client. Set it for your expected request rate.

Make retries safe

Always send a stable idempotency key in the action context. It is what makes a retry safe through the action and connector path, so a repeated call never acts twice in the real world.

Assign an owner for holds

Holds only work if a person or a system handles them. For enterprise and private, assign who watches the review queue or panel and point the notifications at them. For platform, make sure your webhook handler routes escalations to the right reviewer in your product.

Production checklist

• Integration tested against the live schema, not just this guide.
• Tenant ran in shadow long enough to build a representative Shadow AOP Ledger.
• The ledger shows the engine would block and hold exactly what you want.
• Enforcement turned on, with the hard limit AOPs enforced first.
• Daily caps and the rate limit set for your volume.
• Idempotency keys sent on every action.
• A clear owner for holds, and notifications pointed at them.
• For connectors, credentials stored in Selah, never in the agent, and the connector encryption key set in the environment.
• Secrets stored as environment secrets, never in your repository.

After go live

• Watch the audit and the activation funnel for the first days; confirm the mix of permits, holds, and denials looks right.
• Keep refining AOPs as the ledger keeps recording; governance is not frozen at launch.
• Review usage per tenant or sub tenant to understand cost and load.
• Keep your catalog, claim lists, and packs current; the response AOPs are only as good as the source of truth behind them.
• Schedule the personal data purge so expired data is removed automatically.