Technical overview.

Extract, admit, forward.

A principal presents the merchant’s existing credential. Bruiser extracts the customer, evaluates customer policy, and either admits one authorised execution, queues further attempts from that customer, or does not forward them.

Only the authorised execution is forwarded toward the waiting room or the scarce-inventory origin. Inventory allocation remains the merchant’s system. Bruiser does not determine entitlement.

Acquire, renew, release, expire, revoke, handoff.

The lease is permission to attempt allocation, not an inventory hold. Handoff moves the same execution between principals — browser and agent — without changing the customer.

• Acquire — admit the execution.
• Renew — keep it admitted for the life of the attempt.
• Release — return it when the attempt ends.
• Expire — drop an unrenewed lease.
• Revoke — withdraw it by policy.
• Handoff — continue as the same customer from another principal.

The merchant’s customer identifier.

The stable key is a merchant-controlled customer identifier. Browsers, agents, automations, sessions, and devices are principals that carry that identity.

Bruiser does not create a separate customer account. It does not replace authentication. It does not infer whether a principal is a person or software. Cohort assignment, described on Control, uses that same stable identifier. All principals of a customer inherit the same cohort.

Lifecycle operations, not a public catalogue.

The control operations are the execution-lease lifecycle: acquire, renew, release, expire, revoke, and handoff. A redundant attempt by the same customer does not become a second origin execution.

There is no public endpoint catalogue on this site. A private integration is specified against these operations, the merchant’s identity, and the authority check on Architecture.

PostgreSQL, merchant-run.

The gateway persists its own state in PostgreSQL. That database is self-hosted and merchant-run. It holds execution-lease and control-plane state. It is not the inventory system, and it is not the customer-account system.

Embedded, edge, or proxy.

The same product can run as middleware inside the application, on an existing gateway, proxy, worker, or edge layer, or as a reverse proxy in front of the scarce-inventory API. Authority is the requirement. The pattern is an implementation detail. See Architecture.

The merchant sets the policy.

Concurrency, in-flight limits, route-level and execution-level rate limits, deadlines, cancellation, backpressure, dry run, and the enforcement percentage are merchant configuration. Bruiser applies that policy. It does not invent entitlement, and it does not replace the waiting room’s between-customer order.

Liveness and readiness.

The gateway exposes liveness and readiness. Liveness means the process is running. Readiness means it can accept work, including its persistence dependency.

This site is not the gateway health surface. Readiness of the gateway is a merchant-run check against the merchant-run process.

Observed, evaluated, recorded.

Each decision is observed, evaluated, and recorded, including hypothetical decisions for the unenforced cohort during progressive enforcement. Dry-run reporting is described on Control. EAF is incoming allocation attempts divided by authorised executions forwarded. Figures on this site that show EAF are illustrative.

What is written down.

Audit covers the lease lifecycle and the control actions around it. The merchant retains the record with the gateway they run.

• Acquire, renew, release, expire, revoke, handoff
• Queue and reject
• Enforcement cohort
• Emergency control

Ordinary deploy. Independent emergency stop.

The merchant ships the gateway as they ship their own services. A software rollback is the merchant’s ordinary deploy rollback.

Raising or lowering the enforcement percentage, including an immediate return to 0% observation, does not require a platform migration. Observation continues at every enforcement setting, including 0%.

A client beside the existing principal.

An SDK is the companion for principals that already authenticate with the merchant. It requests an execution lease, renews it for the life of the attempt, and releases it when the attempt ends. It does not allocate inventory, and it does not decide entitlement.

The protocol it implements is specified on this page. Further integration material is part of a private demo, not a public catalogue. Request a Private Demo.