Skip to content
Compliance & Architecture

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. Tygart Nexus designs platforms with these requirements as defaults, not as bolt-ons.

Architectural defaults

What every platform we build ships with

  • Local-first / data-residency-aware

    Our default architecture keeps sensitive data in the user's or program's controlled environment. Cloud-hosted variants are available where the program's requirements permit.

  • 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

    Every decision the system makes, and every decision a user makes inside the system, is logged. Audit logs are queryable and tamper-evident.

  • Minimum-necessary access

    Role-based access control with explicit grant flows. No standing-admin patterns.

  • Encryption in transit and at rest

    TLS 1.2+ in transit; AES-256 at rest. Key rotation supported.

Framework alignment

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

    For platforms handling PHI, BAA execution and minimum-necessary access controls are designed in from the start.

  • 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.

Reproducibility

A federal program should be able to inherit a system from us and re-run its analyses from documented inputs

We design for that.

  • Every analysis pipeline has a versioned configuration file. The same configuration + the same inputs produces the same output.
  • AI components have pinned model versions. When we upgrade an underlying model, the previous version remains available for reproducibility.
  • Runbooks ship with every platform. Operations teams can run the system without depending on us.
  • Source code is owned by the customer or licensed in writing — never trapped in our environment.
Audit posture

What audit logging looks like

  • Audit logs

    Queryable, exportable, and tamper-evident. Standard format compatible with common SIEM tooling.

  • 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. Default 7 years for federal-program data.

What we are NOT

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.
Security & architecture briefing

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.