Where the hardware sits
At the customer site—normally in a locked server room, network closet, or controlled IT space with appropriate power, cooling, and physical access. The final location belongs to the customer’s facility and security plan.
Deployment & security
Draw the boundary. Then make every path explicit.
SkilakSpool is placed inside the customer’s physical and network environment. We work with IT, security, and business owners to define who can connect, from where, through which controls, and for what purpose.
Physical placement and access
The three questions every buyer asks first.
The precise answer is site-specific, but the governing pattern is consistent: customer premises, private networks, approved identities, and no unmanaged remote path.
Who can reach it
Only customer-authorized users and administrators. Ordinary use and privileged administration follow separate access roles, with enterprise identity integration where required.
How remote work connects
Through the customer’s managed remote-access path: typically a managed device, MFA, and VPN or zero-trust network access. Skilak does not expose the AI interface directly to the public internet.
Reference architecture
What connects to what.
This is the default logical pattern. The actual VLANs, hostnames, ports, identity flows, update path, logging, and support access are documented in the customer design.
Authorized users
OfficePrivate LAN
RemoteManaged device
AdminPrivileged path
Private HTTPS · Remote access: MFA + VPN / ZTNA
Customer-controlled site
Approved network boundarySkilakSpoolLocked server room / secure IT space
01Private interface
02Model runtime
03Retrieval + data
Optional, approved egress only
IdentityUpdatesSupport
Delivery lifecycle
Stage it. Prove it. Move it. Prove it again.
Staging uses synthetic or explicitly approved data. Customer information is not casually copied to Skilak’s environment. Final network and identity integration happens at the customer site.
- 01
Discover
Define users, workflows, data sensitivity, model needs, identity, network boundaries, facilities, and acceptance criteria.
Deliverable · Solution brief and responsibility map - 02
Stage
Assemble and configure the appliance on Skilak’s controlled staging network using synthetic or customer-approved test data.
Deliverable · Configured build and deployment record - 03
Prove
Load-test the target workflows, exercise retrieval, verify restore procedures, and inspect network behavior before shipment.
Deliverable · Pre-install validation results - 04
Transfer
Move the system under an agreed chain of custody, then rack or place it in the customer’s controlled server room or secure IT space.
Deliverable · Custody and installation record - 05
Connect
Join the approved local network, configure private DNS and HTTPS, integrate identity, and apply the customer-approved firewall policy.
Deliverable · Operational private service - 06
Accept
Run the agreed tests with customer stakeholders, document results, train operators, and hand over support and recovery runbooks.
Deliverable · Signed acceptance package
Control domains
Security built into the operating model.
Controls are selected to fit the customer’s system boundary, policy, risk decisions, and evidence requirements.
Network
Private by default
The user interface is published only to approved internal segments. Model and retrieval services stay on restricted backend networks and are not exposed directly to the internet.
- Private DNS and HTTPS
- Customer-approved firewall rules
- No public inbound service
Remote access
Use the access path you govern
Remote employees reach SkilakSpool through customer-managed VPN or zero-trust network access. Skilak does not create an unmanaged back door around existing controls.
- Managed device
- MFA
- VPN or ZTNA policy
Identity
Named users and deliberate roles
Deployments can use local accounts or approved enterprise identity. Administrative access is separated from ordinary use and aligned to least privilege.
- SSO options
- Role-based administration
- Reviewable access events
Egress
No unapproved AI data path
The target state is no public AI or customer-data egress. If cloud identity, updates, or support require connectivity, each destination is documented and explicitly approved.
- Allowlisted destinations
- Offline operating option
- Traffic review at acceptance
Data
Customer-controlled lifecycle
Source documents, indexes, conversations, logs, backups, and retention rules remain governed inside the customer environment.
- Encrypted transport
- Backup and restore
- Documented retention
Operations
A system your team can run
Configuration, recovery, patching, and escalation procedures are documented during handoff so ownership is clear after go-live.
- Runbooks
- Operator training
- Defined support boundary
Acceptance evidence
Define the proof before the test.
Exact acceptance criteria are agreed during discovery. The following evidence patterns keep results concrete and reviewable.
| Test | Expected outcome | Evidence |
|---|---|---|
| Disconnected rehearsal | The approved AI workflow remains available without a public internet path. | Packet capture, firewall review, and a documented destination inventory |
| Grounded retrieval | Answers based on approved documents return traceable source citations. | Representative question set with reviewer-checked citations |
| Recovery | The service and approved knowledge base can be restored from the defined backup set. | Destroy, restore, and re-query exercise with timestamps and results |
| Model quality | The selected model produces coherent, useful output for the agreed priority workflows. | Customer-approved evaluation set and acceptance record |
Responsibility map
You own the environment. We own the delivery.
A responsibility matrix is finalized for each engagement so operations do not depend on assumptions.
Skilak
- Solution design and staging
- System installation and validation
- Build, recovery, and operator documentation
Customer
- Facility, power, cooling, and network approvals
- Identity, user, data, and retention decisions
- Security authorization and ongoing governance
Shared
- Firewall and access design
- Acceptance criteria and evidence review
- Maintenance windows and support procedures
Map the system
Know where it sits, who connects, and what leaves.
A discovery briefing produces a physical, logical, and responsibility view your business, IT, and security stakeholders can review together.