Authority
Establish named operators and approvers, the exact work permitted, and when changed scope needs new approval. Review an unauthorized-action scenario as well as the successful path.
Security / Acceptance
Controls need evidence. Deployments need acceptance.
The public product model explains what RookHaven is designed to govern. Acceptance requires evidence from the exact candidate, platform, and operating environment under review.
Understand the claim boundary.
| Statement | What it means | What it does not establish |
|---|---|---|
| Design intent | The platform is organized around identity, approval, bounded work, and review. | That every control is independently validated in every environment. |
| Customer responsibility | Authorization, system ownership, operational restrictions, and acceptance authority must be established by the engagement. | That installing an appliance creates permission to assess unrelated systems. |
| Acceptance evidence | Records tie a test, result, reviewer, and any exceptions to a specific baseline. | A certification, a guarantee of resilience, or applicability to an untested hardware family. |
The deployment acceptance gates.
| Gate | Evidence to review | Acceptance question |
|---|---|---|
| Signing custody | Documented custody roles, approval rules, and recovery responsibilities for release signing. | Can the deployment owner account for authority over accepted software? |
| Exact-platform validation | Hardware SKU, firmware, BIOS configuration, Linux distribution, kernel, fwupd version where relevant, and test record. | Does the evidence describe the system being placed, not a similar model? |
| Resilience controls | Where high availability applies: external fencing and independent audit-witness evidence. Fencing prevents conflicting active instances; a witness independently records relevant events. | Have those external dependencies been evaluated in the intended deployment? |
| Recovery exercise | Scenario, baseline, observed result, elapsed time, unresolved deviations, and reviewer. | Has the actual recovery path been exercised and accepted? |
| Independent review | Reviewer scope, findings, remediation status, exceptions, and sign-off. | Which claims were reviewed, what remains open, and who accepts residual risk? |
No gate is marked passed on this page. Status must be supported by retained evidence for the deployment being considered.
Review boundaries before reviewing features.
Assessment workspace
Identify what runs in the protected workspace, which systems are in scope, and which evidence may leave it. Treat workspace isolation and permission to test as separate questions.
Appliance lifecycle
Assign responsibility for custody, updates, recovery, and retirement. A hardware or firmware change can invalidate assumptions made during acceptance.
Evidence handling
Agree what records the customer can inspect, where sensitive evidence is shared, and when access or retention ends. Do not send customer secrets through the public contact form.
Report a security concern.
Use the security-report topic to identify the affected public service and provide a high-level description. Include a safe reply address; an organization is not required for security reports.
You can also email info@stonesignallabs.com. We respond within 24 hours.
Do not attach credentials, customer data, or sensitive exploitation evidence in the initial message. Ask for an appropriate follow-up channel. This form is not an emergency incident-response service.
Report a security issueEvaluate the fit before you commit.
Review the process, then send the environment and questions you want to cover.