How we build software for environments that require security, auditability, and reproducibility.
Federal programs and regulated commercial environments share a set of requirements that consumer software typically doesn't address: data sovereignty, deterministic behavior, complete audit trails, role-based access, and the ability for an auditor or successor team to reproduce a system's behavior from its documented inputs. For client deployments, Tygart Nexus scopes these requirements before implementation and documents the controls that actually apply.
Standard architecture for client deployments
Local-first / data-residency-aware
For client deployments, our standard architecture is designed to keep sensitive data in the user's or program's controlled environment when requirements permit. Cloud-hosted variants are available where the program's requirements allow them.
Deterministic by design
Same inputs produce the same outputs. Where AI components introduce nondeterminism (e.g., generative-AI extraction or drafting), we surface confidence scores and pin model versions so output is reproducible within a documented tolerance.
Complete audit trail
Client deployments are scoped with user-action and system-decision logging requirements. Where needed, audit logs can be made queryable, exportable, and tamper-evident.
Minimum-necessary access
Role-based access control with explicit grant flows is the standard design target. Standing-admin access is avoided unless a documented operational exception requires it.
Encryption in transit and at rest
Client deployments are designed for encryption in transit and at rest using the controls available in the selected hosting and storage stack; key-rotation expectations are documented per deployment.
How we map to the frameworks federal programs care about
In order of how frequently it comes up in federal program conversations:
NIST SP 800-171
We design platform components to align with the SP 800-171 control families. We can produce a self-assessment scoring against the controls relevant to a specific deployment.
NIST SP 800-53
For programs operating at moderate or high impact levels, we map our architectural decisions to the relevant control families.
NIST Cybersecurity Framework (CSF)
Internal posture aligned to Identify / Protect / Detect / Respond / Recover.
HIPAA
Healthcare engagements are scoped under a HIPAA-aware implementation model. Before PHI touches any Tygart Nexus-controlled system, required agreements and data-handling controls must be documented.
FedRAMP
We have not pursued FedRAMP ATO. For programs requiring FedRAMP-authorized infrastructure, we deploy onto an existing FedRAMP-authorized cloud (AWS GovCloud, etc.) under the program's authorization umbrella.
CMMC
We have not pursued CMMC certification. For CDI-handling work, we partner with a CMMC-assessed prime where required.
A federal program should be able to inherit a system from us and re-run its analyses from documented inputs
We design for that.
- Analysis pipelines are designed with versioned configuration so the same configuration and inputs can be re-run where reproducibility is required.
- AI components can pin model versions for client deployments. Upgrade and reproducibility expectations are documented before launch.
- Runbooks are included for client deployments so operations teams can run the system without depending on tribal knowledge.
- Source code is owned by the customer or licensed in writing — never trapped in our environment.
What audit logging looks like
Audit logs
Queryable, exportable, and tamper-evident where required by the deployment scope. SIEM-compatible formats can be planned during implementation.
User-action audit trail
Captures who did what, when, from which session.
System-decision audit trail
Captures what the system decided autonomously, what data it relied on, and what confidence it assigned.
Retention
Configurable per regulatory requirement. Retention periods are documented per federal-program or regulated deployment.
So federal program staff can rule us in or out quickly
In the spirit of being useful, here is what we are NOT trying to be.
- We are not a CMMC-certified or FedRAMP-ATO'd prime. If your program requires either as a prime requirement, we are not the right prime; we may be the right sub.
- We are not an SBA set-aside-certified company. If your program requires an 8(a), HUBZone, WOSB, or SDVOSB prime, we are not the right prime; we may be the right sub or technology partner.
- We are not a body shop. Our model is platform engineering with engagement around platform operation, not staff augmentation.
- We do not auto-submit. Any submission to a federal portal happens through human action.
Want a working session on our security posture?
We brief federal program staff and prime contractors on our architectural defaults, framework alignment, audit posture, and what we will and will not commit to. Direct conversations.