Craft Wall proof of concept: demo stand checklist and acceptance criteria

What a proof of concept covers

A proof of concept installs Craft Wall on an agreed server, connects real sources and checks the operator workflow against written criteria. It ends with a review of the results.

A 30-minute demonstration on our stand answers most questions. Choose a proof of concept when the decision depends on your sources, your network or your acceptance procedure.

Duration, server and participants are agreed at kick-off. The plan below is the default sequence; remove the steps that are out of scope.

• Book the 30-minute demonstration →
• Partner programme and project registration →

Technical checklist for the demonstration stand

Prepare the stand before the engineer joins. Every item maps to a step in the plan below.

• Server: Linux, an NVIDIA GPU and video outputs for the planned display count; CPU, RAM, storage and network sized for the sources. Use the sizing calculator or the reference specifications delivered with the licence.
• Displays: an LCD or LED wall connected to the server outputs. Note the layout in rows and columns, the resolution and the bezel widths.
• Network: the server must reach every source — the camera VLAN, the NDI segment, remote desktop hosts and dashboard servers. Note firewall rules and whether the segment is isolated.
• Operator workstation: a laptop or tablet with a current browser on a network that reaches the server.
• Test sources of each type you plan to show: at least one camera stream, one web dashboard and one remote desktop; NDI, capture or conferencing if relevant.
• Accounts: an administrator, an operator and a viewer account to show roles; identity-provider details if SSO or LDAP is in scope.
• An event source for alarm scenarios, agreed with the engineer, if alarm switching is part of the evaluation.
• A second server if hot standby is part of the evaluation.

• Size the server →
• Deployment and access requirements →

Preparing the customer's sources

Send the source list before the session so the engineer can prepare scenes. Do not send passwords by email; agree a secure channel for credentials.

Describe the scenes you need: routine monitoring, shift handover, incident review, meeting. Name the operators and their roles.

Proof-of-concept plan

Eight steps, run in order. Each step produces a record: what was connected, what was measured and what remains open.

1. Kick-off: scope, success criteria, participants and schedule; the source list and display layout are confirmed.
2. Installation: Craft Wall on the agreed server — your hardware per the reference specifications or a preconfigured server; network and display outputs verified.
3. Source onboarding: every source in the list is connected and displayed; problems are recorded with an owner and a next step.
4. Scenes and operator workflow: scenes for the agreed tasks are built; operators work from the browser console on a laptop or tablet.
5. Automation: schedules and alarm scenarios are configured for the agreed triggers; the acknowledgement process is tested.
6. Access and security: roles and, where scoped, SSO, MFA and LDAP; a check of who can view sources, change layouts and administer the system.
7. Resilience: source loss, network interruption and, where scoped, hot-standby switchover; recovery times are measured and recorded, not assumed.
8. Acceptance review: criteria are checked one by one, results are documented and the project decision is taken.

Acceptance criteria

Record measured values, not target values, in the protocol. This page does not set a guaranteed recovery time or capacity figure; those come from your test.

• Every source in the agreed list is displayed at the agreed resolution and frame rate.
• Operators complete the agreed tasks from a browser on a laptop or tablet without a desktop client.
• Scene changes reach the wall within the time recorded during the test; dashboards are legible from the operator position.
• Roles restrict source access, layout changes and administration as specified.
• Schedules and alarm scenarios switch to the agreed scene; the return to routine operation is checked and recorded.
• Source loss and reconnection behave as recorded in the resilience test; hot-standby switchover time is recorded where in scope.
• The system runs through the agreed observation period without operator intervention.
• Configuration, scene list and results are documented and handed over.

Materials handed over

The proof of concept and the later delivery hand over the following materials.

• Licence and server inclusions →
• Discuss a proof of concept →