ARCHITECTURE
PRINCIPLES
The design decisions that make Peveka safe for the most sensitive capital program data — stateless processing, provider-level isolation, and adversarial input hardening.
Stateless, Wipe-on-Close Architecture
Your data never persists.
All project data — schedule files, cost reports, contract documents — is processed exclusively in volatile RAM. No write operations occur to persistent storage during analysis. On session close, memory is cryptographically flushed. No session state, no cached file, no query log persists after the session ends.
Volatile RAM Processing Only
When you upload a P6 XER file, a Cobra export, or a PDF contract to Peveka, that file is loaded into volatile RAM and processed in-memory. It is never written to a database, a file system, an object store, or any other persistent medium. The analysis runs entirely in the session's allocated memory space. When the session ends, that memory space is released and overwritten.
- ✓All project data processed exclusively in volatile RAM
- ✓No write operations to any persistent storage medium
- ✓No database rows, no file system writes, no object store entries
- ✓Session memory released and overwritten on close
Cryptographic Memory Flush
Session close triggers a cryptographic memory flush — the allocated memory space is overwritten with random data before release, making recovery impossible even with physical access to the underlying hardware. This is not a software-level delete operation; it is a hardware-level overwrite. The session lifecycle is enforced at the infrastructure layer, not the application layer.
- ✓Hardware-level memory overwrite on session close
- ✓Random data written to allocated memory before release
- ✓Not a software delete — a physical overwrite
- ✓Session lifecycle enforced at infrastructure, not application layer
The Zero-Training Guarantee
Your data never trains our models.
Client project data is never used to train, fine-tune, update, or improve any AI model — including the models Peveka uses for inference. This guarantee is not a policy position; it is enforced at the architecture level through provider selection and contractual commitments with every AI provider in the inference layer.
Architecture-Level Enforcement
The zero-training guarantee is not contingent on a policy that could be changed — it is enforced through the providers Peveka uses for inference. Every AI provider in the Peveka inference layer operates under contractual commitments that prohibit use of customer data for model training. For federal deployments, inference routes through government cloud backends that are structurally separated from commercial model training pipelines.
- ✓Enforced through provider-level contractual commitments
- ✓Not a policy — structural separation from training pipelines
- ✓Government cloud backends for federal programs
- ✓Contractual audit rights for enterprise clients
No Retention, No Training, No Fine-Tuning
The zero-training guarantee covers all three vectors: no client data is retained for training purposes, no client data is used for fine-tuning existing models, and no client data is used to update model weights in any form. The guarantee extends to all data types processed by the engine: schedule files, cost data, contract documents, engineering drawings, and query text.
- ✓No retention of client data for training purposes
- ✓No fine-tuning using client data
- ✓No model weight updates derived from client queries or uploads
- ✓Guarantee covers all data types: schedules, cost, contracts, drawings, queries
Provider-Level Data Isolation
No shared inference infrastructure.
Each engagement routes through dedicated, isolated inference infrastructure. There are no shared cloud AI endpoints, no shared inference queues, and no mechanism by which one client's data can be processed on infrastructure also processing another client's data. Isolation is enforced at the provider level, not just the application level.
Dedicated Inference Infrastructure
Peveka's provider-agnostic AI layer routes each deployment to inference infrastructure that is dedicated to that engagement. In government cloud configurations, this means a dedicated enclave within the client's own authorized government cloud environment. In commercial configurations, this means provider configurations that enforce data isolation at the infrastructure layer.
- ✓Dedicated inference infrastructure per deployment
- ✓No shared AI endpoints across clients
- ✓No shared inference queues or batch processing
- ✓Isolation enforced at provider infrastructure layer, not application layer
Tenant-Level Data Isolation
At the application layer, every organization on the Peveka platform is a fully isolated tenant. Files, knowledge base entries, audit history, and session data are scoped exclusively to the tenant that owns them. There is no shared data layer, no cross-tenant query path, and no mechanism by which one organization's data can be accessed by another. Tenant deletion cascades to all associated data.
- ✓Files, knowledge base, and audit history scoped to tenant
- ✓No shared data layer across organizations
- ✓No cross-tenant query path — isolation enforced at data layer
- ✓Tenant deletion cascades to all associated data and session history
Adversarial Input Hardening
Schedules cannot manipulate the audit engine.
The PARS DIQ deterministic validation layer runs before any AI inference processes client data. It is a hard gate: if a schedule fails structural validation, no AI mode processes it. This prevents adversarially crafted inputs — schedules engineered to produce favorable audit results — from reaching the inference layer.
Deterministic Gating Architecture
Every schedule submitted to the Peveka forensic engine passes through PARS DIQ — the Pre-Audit Readiness and Schedule Data Integrity Qualifier — before any AI inference layer runs. PARS DIQ validates schedule structure, predecessor logic, calendar assignments, and constraint integrity purely in code. If PARS DIQ detects structural anomalies, the AI modes are blocked. The gate is not bypassable, not even by administrators.
- ✓Hard gate before any AI inference runs
- ✓Predecessor logic, constraints, and structure validated in code
- ✓AI modes blocked on PARS DIQ failure — not warned, blocked
- ✓Gate not bypassable at any permission level
Statistical Anomaly Detection
PARS DIQ includes statistical anomaly detection designed to identify schedules that have been engineered to comply with metric thresholds without reflecting actual project conditions. Patterns consistent with compliance gaming — artificially inflated float, engineered critical path length index, suspiciously uniform resource loading — are flagged as anomalies and surfaced to the analyst before AI inference runs.
- ✓Statistical anomaly detection for engineered compliance patterns
- ✓Artificial float inflation and CPLI gaming detected
- ✓Suspiciously uniform resource loading flagged
- ✓Anomaly report generated before AI inference proceeds