Security and risk counterweight
Lead with the speed or capability, put the controls that bound it immediately after, then hand over the implementation detail.
Section sequence
6sections, in the order the visitor meets them. Bar height is the section's weight in the page.
- OrientCapability promise
- DemonstrateThe fast thing, happening
- ProveControl layer
- ProveAudit and evidence cards
- NavigateImplementation route
- ConvertSecurity review contact
How the page argues
- 1
Lead with the capability, honestly and specifically.
- 2
Show the fast thing actually happening, so the promise is grounded.
- 3
Place the control layer immediately after, not three scrolls later.
- 4
Give the audit and evidence cards a security reviewer can forward internally.
- 5
Route to the implementation detail: deployment model, data handling, permissions.
- 6
Offer a contact path aimed at the security review itself.
What each section has to be
- OrientCapability promise
- The speed or power claim, specific and measurable, stated without hedging.
- DemonstrateThe fast thing, happening
- The acceleration shown in the product, so the controls that follow have something real to bound.
- ProveControl layer
- The specific controls that bound the capability: permissions, scopes, review gates, limits.
- ProveAudit and evidence cards
- Certifications, logs, data residency and retention, in a form a reviewer can circulate.
- NavigateImplementation route
- Deployment models, isolation options and admin documentation for whoever will actually run it.
- ConvertSecurity review contact
- A path explicitly for the review — questionnaire, DPA, architecture call — not the generic sales form.
Is this the right sequence?
Who it is for
A buying pair: the practitioner who wants the speed and the reviewer who must approve the risk.
Products it suits
Products where acceleration itself creates a governance question — generated code, agent actions, broad access.
Not for
Consumer tools where enterprise controls are not part of the decision and would only add weight.
Evidence strategy
Which proof modes carry the page, in the order they land.
- Primary: the capability, demonstrated, because controls on a product nobody wants are irrelevant.
- Secondary: named controls, which answer the consequence question at the moment it forms.
- Tertiary: forwardable evidence, which lets the champion carry the argument internally.
CTA plan
What the page asks for, what it offers instead, and where.
- Primary
- Start with the controls already on
- Secondary
- Request the security package, or read the deployment models
- Placement
- Self-serve start after the control layer; the review contact sits with the evidence cards, not in the footer.
Responsive behavior
What the sequence has to do when the viewport stops cooperating.
- Control cards go from a three-column grid to a stacked list, keeping each control's scope line intact.
- Certification badges stay legible and labelled; never render them as an unlabelled logo strip.
- The implementation route becomes a plain link list on mobile rather than a comparison table.
Anti-patterns
The failure modes that make this sequence stop working.
- Burying security below the fold on a product whose main objection is risk.
- Compliance badges with no dates, scopes or auditors.
- Leading with controls, which sells safety to someone who has not yet wanted the product.
- A security page that a reviewer cannot forward as evidence.
Build spec
What an agent needs in order to build Security and risk counterweight: what each section must contain, the copy rule that keeps it honest, the slots to resolve from your product, and the order to build in.
Section specs
- 1.
Capability promise
- Specific speed or power claim
- The measure behind it
- Who benefits
Copy rule: Quantify the acceleration; 'fast' without a number invites the objection unanswered.
- 2.
The fast thing, happening
- Real product capture
- Elapsed time visible
- Realistic input
Copy rule: Show elapsed time honestly, including any wait.
- 3.
Control layer
- Three to six named controls
- Scope or granularity per control
- Default state per control
- Who can change it
Copy rule: State each control's default, because defaults are the real policy.
- 4.
Audit and evidence cards
- Certifications with scope and date
- Log and retention facts
- Data residency options
- Subprocessor list link
Copy rule: Every certification carries its scope, auditor and date.
- 5.
Implementation route
- Deployment models
- Isolation or tenancy options
- Admin documentation link
Copy rule: Name the deployment models plainly, including what each does not offer.
- 6.
Security review contact
- Questionnaire or package request
- DPA route
- Architecture call option
Copy rule: Name the artifact the reviewer will receive.
Content slots
- accelerationClaim
- The measurable speed or capability gain, with its measurement basis.
- controlInventory
- Controls with scope, default state and who may change them.
- complianceEvidence
- Certifications with scope, auditor and date, plus retention and residency facts.
- deploymentOptions
- Deployment and tenancy models, with the trade-offs of each.
- reviewPackage
- What the security package contains and how a reviewer requests it.
Build order
- Write the acceleration claim with its measurement basis.
- Capture the capability in the product with honest elapsed time.
- Enumerate controls with their default states; defaults come before descriptions.
- Assemble compliance evidence with scopes and dates, discarding anything undated.
- Add deployment options, then the review contact naming the deliverable.
QA checks
- The capability claim carries a number and a measurement basis.
- The control layer appears within one scroll of the capability demonstration.
- Every control states its default state.
- Every certification names scope, auditor and date.
- The review contact names the artifact the reviewer receives.
Agent tags
The vocabulary an agent matches this recipe on.
- security-counterweight
- control-layer
- audit-evidence
- deployment-model
- review-contact