Security & Governance
Controls we can describe. Nothing we have not earned.
AVC handles clinical documentation, authorization records, and the reasoning applied to them. This page sets out the security baseline the product is being built to and the governance rules it operates under, stated as controls, not as certifications.
AVC prepares the decision. Humans make it.
Read this first
Where AVC actually is.
AVC is pre-validation. There is no production deployment, no customer organization using the system, no pilot underway, and no customer or patient data held anywhere in it.
Everything below is therefore a design requirement for the MVP: the baseline the system is being built to meet before it processes a single real case. It is not a description of a running production environment with an operating history, and we are not going to write it as though it were.
No certification, attestation, or authorization has been achieved, and none is claimed. AVC holds no HIPAA attestation, no SOC 2 report, no FedRAMP authorization, and no Authority to Operate. No third-party security audit or penetration test has been performed. When any of that changes, this page will say which line changed and when.
Governance
Human authority is the design, not a disclaimer.
AVC prepares decisions. Authorized clinicians and decision-makers retain authority over every one of them. The product is constructed so that it cannot quietly acquire that authority: the conclusions it is capable of producing are a fixed, published set, and none of them is a determination.
AVC never emits an eligibility verdict. The two determination labels a benefits system would produce are prohibited outputs. No classification path in the product can generate them, and AVC does not make statutory benefits determinations of any kind.
AVC does not
- Determine Veteran eligibility
- Diagnose dental disease
- Approve or deny treatment
- Replace a licensed clinician
- Submit a request without a human
AI boundaries
What the models are allowed to touch.
AI is used for reading and organizing documents. It is not used for judgment that belongs to a clinician or to a benefits decision-maker. The line is drawn in the product, not left to operator discretion.
AI may assist with
- Optical character recognition on uploaded documents
- Structured extraction of fields from unstructured text
- Document classification
- Summarization
- Gap detection (identifying an element that appears to be absent)
- Cross-document comparison
- Inconsistency identification
- Drafting administrative summaries for human review
AI may not
- Autonomously diagnose dental disease
- Determine treatment candidacy
- Determine statutory Veteran eligibility
- Grant or deny authorization
- Submit a treatment request
- Override a clinician
- Alter a source record
Deterministic rules first
If a reliable rule resolves a question, AVC uses deterministic logic rather than a prediction. A model is not asked to guess at something the rule already answers. This keeps the explanation short, stable across cases, and reviewable by a person who does not work in machine learning.
MVP design requirementModel governance
Where AI is used, AVC retains the record needed to reconstruct what happened:
- Model identifier
- Model version
- Input context
- Output
- Confidence, where the model produces one
- User correction, where a human changed the result
- Timestamp
The reliability invariant
A technical failure never becomes an authorization conclusion.
This is the safety property the rest of the system is arranged around. If a document fails to parse, an extraction returns nothing usable, a dependency is unavailable, confidence falls below threshold, or a rule cannot be evaluated, the case does not silently resolve in either direction.
It is routed to a human, with the reason stated. Degradation is visible. The failure mode of AVC is “a person needs to look at this,” never a conclusion that happens to be produced by an outage.
Explainability
Every material flag traces back.
A flag a reviewer cannot interrogate is a flag they will learn to ignore. Each one carries its full provenance so a person can agree with it, override it, or ask a better question, and so that the override is itself part of the record.
MVP design requirement- Source evidence
- Rule
- Rule version
- Reason
- System classification
- Human disposition
Source records stay authoritative
AVC does not alter original clinical documents, VA records, or source authorization records. Extraction produces a structured layer alongside the source; corrections are recorded as corrections against it. The document a reviewer opens is the document that was uploaded.
Security baseline
Fifteen controls, described plainly.
These are the controls the MVP is required to implement before it handles real case data. Each is a mechanism, not a badge. Where a control is a written procedure rather than a technical measure, it is labelled that way.
Protecting data
Encryption in transit
All traffic between clients and AVC services is encrypted.
Encryption at rest
Stored documents, extracted data, and case records are encrypted on disk.
Secure secrets management
Credentials and service keys are held in a managed secret store, not in source, configuration files, or environment dumps.
Key rotation
Encryption keys and service credentials have a defined rotation schedule and a rotation procedure that does not require downtime.
Encrypted backups
Backups carry the same encryption expectation as primary storage.
Restore procedures
A backup is only a control if it restores. Restores are exercised, not assumed.
Controlling access
Multi-factor authentication
MFA is required for account access, including administrative access.
Role-based access control
Permissions attach to a role, not to a person's history in the system. Four roles, described below.
Tenant isolation
Case data is scoped to the organization that owns it. Cross-organization access requires an explicit, defined workflow.
Access logging
Who accessed which case, and when, is recorded, including administrative access.
Operating the system
Vulnerability management
A defined process for identifying, triaging, and remediating vulnerabilities, with severity-based timelines.
Dependency management
Third-party dependencies are inventoried and monitored for known vulnerabilities.
Incident-response procedures
A written procedure covering detection, containment, customer notification, and post-incident review.
Ending the data lifecycle
Data-retention policy
Every category of data has a stated retention period and a reason for it. Data is not kept because deleting it is inconvenient.
Secure-deletion policy
A defined procedure for removing data at end of retention, on customer request, and at contract termination, including from backups.
Access
Four roles, least privilege.
Access is granted by role and scoped to what the role actually needs to do the work. There is no general-purpose account that can see everything, and administrative access is not exempt from logging.
MVP design requirementPractice User
Creates and manages cases for their own organization. No visibility into other organizations, no system-level settings.
Reviewer
Reviews assigned cases: the flags, the evidence behind them, and the recommendations. Access follows assignment.
Organization Administrator
Manages users within their organization and the settings that organization is permitted to change. Not a superuser.
AVC Administrator
Restricted system-level access for operating the platform. Deliberately narrow, and logged like any other access.
Tenant isolation
Cases belonging to one customer organization are not accessible to another customer organization unless access is explicitly authorized through a defined workflow. Isolation is a property of how case data is scoped and queried, not a filter applied at the interface.
Where a legitimate cross-organization workflow exists (a practice and an administrator working the same case), that path is explicit, authorized, and recorded in the case history.
Auditability
Append-only activity history.
A case is reconstructable after the fact. Entries are appended, not edited in place, so the history shows what the system concluded, which rule version produced it, and what a human did about it.
MVP design requirementWhat we have deliberately not built
A full cryptographic ledger (tamper-evident hashing across the audit chain) is not in the MVP. It is deferred until a contractual or regulatory requirement justifies the cost and operational weight of maintaining it.
We would rather state that plainly than let “audit trail” imply a guarantee we have not engineered. If a pilot or contract requires it, it becomes a scoped piece of work, not a marketing sentence.
Recorded events
- Case creation
- Document upload
- Extraction
- User correction
- Rule execution
- Rule version
- Flag generation
- Human modification
- Review recommendation
- Export
- Submission state
Data minimization
The safest record is the one we never collected.
AVC collects only what the authorization workflow requires. Fields are added because a step in the work needs them, not because they might be interesting later.
AVC does not collect SSN
Social Security numbers are not collected, not stored, and not accepted as an identifier anywhere in the product. The authorization workflow does not require one, so the field does not exist.
Every sensitive field is accounted for
Each sensitive field carries four attributes before it is allowed into the schema:
- Purpose
- the workflow step that needs it
- Source
- where the value comes from
- Access policy
- which roles can read it
- Retention rule
- when it goes away
Claims discipline
What this page deliberately does not say.
Security pages are where unearned language collects. So, explicitly: AVC has not achieved and does not claim any of the following.
- A HIPAA attestation or third-party HIPAA assessment
- A SOC 2 examination or report of any type
- FedRAMP authorization at any impact level
- An Authority to Operate from any federal agency
- A completed third-party security audit or penetration test
- Any relationship with, endorsement by, or approval from the U.S. Department of Veterans Affairs
Where a pilot organization has a security requirement we do not yet meet, we would rather hear it during a review than discover it after a contract. Questions about controls can come through the pilot request form.