Papyrus — government
Government support
Support for Papyrus appliances deployed in government, accredited, and disconnected environments. Contract-specific terms always control, and the government mailbox keeps those requests separate from commercial support. If you are using the commercial offer, use commercial support.
Support channel
government@beaglabs.com
Support terms
How support works
First-response targets are commitments to engage and triage. Resolution time depends on the fault, environment, and any third-party dependency involved.
Email government@beaglabs.com. Include the severity and deployment ID in the subject line, for example [Sev 2] 7f3a91c4 — onboarding completes but no licence accepted.
Business hours are Monday to Friday, 09:00–18:00 US Eastern, excluding US federal holidays, unless the governing contract establishes different coverage.
Severity 1 reports are reviewed outside normal business hours on a best-effort basis. Any 24×7, mission, or incident-response coverage is governed by the applicable order, task order, or support agreement.
If your agreement names a COR, program manager, security officer, prime contractor, or other required point of contact, keep that person on the support thread and follow the communication rules in the agreement.
Do not send CUI, export-controlled data, classified information, credentials, tokens, or production secrets over ordinary email. Send identifiers and sanitized diagnostics first so we can establish the approved exchange path.
Severity targets
| Severity | First response | Updates |
|---|---|---|
| Severity 1 | 4 business hours | Every business day until resolved |
| Severity 2 | 1 business day | Every 2 business days until resolved |
| Severity 3 | 3 business days | As the request progresses |
Severity 1
The appliance is down or unusable in production, no workaround exists, and mission-critical work has stopped.
Severity 2
Functionality is degraded or a subset of workflows fails, but a workaround remains available.
Severity 3
Configuration questions, documentation gaps, cosmetic defects, compliance-evidence questions, and feature requests.
What to include
Papyrus does not call a Beag Labs control plane and we receive no appliance telemetry. The details you send are what let us reproduce and isolate the issue quickly.
- Deployment ID
- Shown on the appliance onboarding page and returned by /api/config/public. It is the identifier we use to locate the licence record.
- Image tag
- The exact Papyrus image tag deployed in the environment, for example 0.1.1.
- Environment context
- Cloud, on-premises, disconnected, or enclave context; region where applicable; VM or host size; and the deployment method used.
- Container state
- `sudo docker ps -a` and `sudo docker logs papyrus --tail 200`, with sensitive values removed before transmission.
- Timeline
- When it last worked and what changed immediately before the issue — image update, network policy, identity change, model endpoint rotation, or boundary-policy update.
- Authorization context
- If relevant, provide the control, SSP, POA&M, STIG finding, or ATO-package reference tied to the Papyrus component. Do not email CUI or classified material unless your agreement authorizes that channel.
What is covered
In scope
- ✓The Papyrus container image, API, and first-run onboarding in government, accredited, and disconnected environments.
- ✓Deployment artifacts maintained by Beag Labs, including Azure Government deployment failures attributable to those artifacts.
- ✓Licence issuance, activation, renewal, and deployment-ID questions.
- ✓Model endpoint configuration for Azure OpenAI, OpenAI-compatible gateways, and customer-hosted inference inside the approved boundary.
- ✓Published image upgrades, rollback guidance, and appliance-level troubleshooting.
- ✓Papyrus component evidence and documentation used by the customer in RMF, ATO, SSP, POA&M, CMMC, or similar assessment workflows.
Outside standard support
- —Cloud-provider incidents, quota limits, region capacity, or outages in customer-managed infrastructure.
- —Customer network, firewall, DNS, private endpoint, identity, cross-domain, and egress policies unless separately scoped.
- —Availability or correctness of customer-hosted or third-party model endpoints.
- —Custom integrations, connectors, prompts, or mission workflows created under a separate services statement of work.
- —Operating-system administration, STIG remediation, or platform hardening beyond the Papyrus deployment artifacts unless included in the governing agreement.
- —Maintenance of an agency authorization package beyond the Papyrus evidence and component artifacts Beag Labs is responsible for providing.
Before you write
Deployment parameters, disk layout, and health checks for Papyrus appliances, including Azure Government deployments where supported.
GET /api/config/publicReports the deployment ID, licence state, and active profile without requiring access to a Beag Labs control plane.
GET /api/license/statusReports whether the appliance licence is active and when it expires.
sudo docker exec papyrus node /healthcheck.mjsRuns the appliance health check. Capture the result inside the approved environment and sanitize it before sending by email.
Need an engineer?