Rariveil Scope Prep Request

FOR SECURITY DELIVERY TEAMS

It prepares the packet — or it holds the line.

Scope Prep turns sanitized structured scope/context into a first-draft kickoff packet. If context is insufficient, it refuses the draft and produces a clear rejection report instead.

CONTEXT SUFFICIENT PACKET RELEASED
CONTEXT INSUFFICIENT HELD + REJECTION REPORT

No AI-driven testing. No invented findings.

Scope Prep is input-driven and rule-gated. It does not test systems, validate vulnerabilities, or generate security findings.

Input-driven Only sanitized structured context is used.
Rule-gated Missing context produces a hold, not a guessed packet.
Claim-safe No vulnerability claims, exploit narratives, or proof language.

Draft when ready. Refuse when context is missing.

Scope Prep is strongest when it does not try to impress you with a half-built workflow. It prepares a first-draft kickoff package only when the input context is adequate.

One threshold. Two honest paths.

RELEASED

When context is sufficient

  • Phased kickoff strategy
  • SOW amendment draft
  • Jira draft tickets
  • Waiver draft templates
  • Local self-contained HTML dashboard

HELD

When context is insufficient

  • Rejection report
  • Missing context checklist
  • Client context request

No misleading output. No half-finished SOWs.

Could a PM use this tomorrow?

Could you hand this exact output to a PM before a kickoff call as a starting draft, or would it create more cleanup work than it saves?

A narrow intake, not a data dump.

You send structured, sanitized context only. These fields help decide whether a kickoff packet can be prepared — or whether the request should be held.

Company or team type MSSP, internal security team, consulting team, delivery PM
Engagement type Kickoff planning, scope clarification, pre-sales handoff
Asset type Web app, API, identity system, cloud service, internal platform
Environment Production, staging, internal, external, unknown
Scope status Confirmed, proposed, incomplete, unclear
Asset owner Known, unknown, pending confirmation
Auth boundary Known, unknown, customer must confirm
Data sensitivity Public, internal, customer data, regulated, unknown
Evidence source Client-provided scope sheet, PM notes, sanitized architecture notes
Decision owner PM, delivery lead, customer owner, security lead
Do not include:

Credentials, secrets, PII, raw customer data, mapping files, screenshots with sensitive identifiers, or live target data.

Continue to contact

The PM remains in control.

Edit the draft

Reject bad assumptions

Resequence phases

Approve what reaches the client

Own the delivery judgment

Sanitized context only.

Allowed

Sanitized structured scope/context

Sanitized assumptions and constraints

Sanitized phase preferences

Not allowed

Raw customer data

Credentials, secrets, or PII

mapping.json or reverse maps

Scan results or live target data

No scanning. No crawling. No fetching. No target contact. No active validation. No proof execution.

Ask for a narrow review packet.

Send only sanitized structured context. The result is either a first-draft kickoff packet or a clear rejection report explaining what is missing.