Customer boundary
Document the sites, network zones, permitted administration paths and any disconnected-operation requirement.
Deployment qualification
Know the boundary and prerequisites before a POC.
Deployment is an architecture review, not a published appliance tier list. We qualify the customer-controlled environment, responsibilities, data paths and acceptance tests before representing any topology as suitable.
Intended evaluation topology
A controlled POC places the deterministic decision path inside the agreed customer environment. Exact hardware, isolation, identity and operating constraints are established during qualification; no capacity figure or failover commitment is published here.
Customer-controlled boundary
- Approved input path
- Deterministic decision
- Event evidence
- Customer custody
Runtime egress must be verified as an acceptance criterion
Simplified evidence path
Evidence status
Claims and evidence must share the same boundary.
Identity and authority
Name the POC identity stand-in, authorised roles, policy owner and evidence-custody responsibilities. Production AD and Kerberos remain future integration work.
Inputs and endpoints
Agree approved browser submission paths as acceptance scope. The current POC has no endpoint agent or MV3 extension.
Measurement
Define representative inputs, rated request conditions, expected actions and evidence outputs before testing performance or coverage.
Stage gates
Every stage ends with a record and an explicit decision.
- 01
Boundary discovery
Record zones, paths and constraints
- 02
Responsibility assignment
Name decision and evidence owners
- 03
Test approval
Agree conditions and pass evidence
- 04
Controlled installation
Deploy inside the approved environment
- 05
Observe and tune
Record results, exceptions and blind spots
- 06
Authorised exercise
Make an explicit go or stop decision
The flow shows the proposed evaluation sequence, not an automatic production rollout.
Assurance artifacts
Available and missing artifacts are equally explicit.
Architecture boundary record
Agreed zones, interfaces, owners and prohibited paths.
Responsibility matrix
Customer and SentraMind responsibilities with named acceptance owners.
Acceptance test plan
Conditions and pass/fail evidence agreed before execution.
Production HA design
Not a supported tier or achieved capability in the current POC.
Offline update release package
Verification and rollback are design objectives; complete lifecycle evidence is absent.
Current limitations
Evaluation should begin with the known gaps.
These constraints are not hidden in footnotes. They shape the test plan and procurement decision.
- 01 Customer provides an isolated evaluation environment and approved synthetic or reviewed test material.
- 02 A reliable local time source is required when evaluating event chronology and chain integrity.
- 03 The POC uses development identity; no production directory integration is implied.
- 04 Observe, tune and enforce stages are evaluation concepts whose transition authority must be agreed.
- 05 No deployment begins with an unqualified claim of endpoint, model, HA or throughput coverage.
Evaluation method
Close the review with reproducible evidence.
The review progresses through boundary discovery, responsibility assignment, test-plan approval, controlled installation, observation, tuning and an authorised enforcement exercise. Each stage ends with evidence and an explicit go/no-go decision; it is not an automatic production rollout.
Deployment cutaway
POC objective: the data path terminates inside the customer boundary.
Outside boundary×Runtime zero-egress objective
Customer-controlled boundary
Approved test input
SentraMind control plane
Local event record
Architecture objective · not a verified appliance claim
01
Identity, connectivity, HA and custody are acceptance scope.