ProofLayer Specification

Home / ProofLayer / ProofLayer Specification

ProofLayer

The Internet’s Compliance Layer

Overview

ProofLayer is an open-source compliance infrastructure designed to provide continuous, verifiable security and compliance operations for organizations and digital services.

ProofLayer supports compatible SOC 2 evidence and control workflows while providing infrastructure for public-facing SOC 3 transparency reporting. The system is designed to transform compliance from a periodic, document-driven process into a continuous operational capability.

ProofLayer provides automated evidence collection, control validation, compliance monitoring, audit preparation, transparency reporting, and machine-readable compliance discovery.

ProofLayer is designed around modular components that can operate independently or together.

Goals

ProofLayer shall:

Support continuous compliance operations.
Provide compatible workflows for SOC 2 evidence collection and control validation.
Support the generation of public-facing SOC 3 transparency information.
Collect, organize, validate, and preserve compliance evidence.
Detect changes that may affect compliance posture.
Provide machine-readable compliance information.
Support cryptographic verification and tamper-evident evidence records.
Enable self-hosted, cloud, hybrid, and private infrastructure deployments.
Minimize vendor lock-in.
Support human review and auditor participation.
Provide extensible architecture for additional compliance frameworks.

ProofLayer shall not represent itself as an auditor or independently certify that an organization has achieved SOC 2 or SOC 3 compliance unless such a determination is made by an appropriately authorized independent auditor.

Design Principles

Continuous Compliance

Compliance controls should be evaluated continuously where technically possible rather than only during periodic audit preparation.

Evidence-Based Verification

Compliance status should be supported by traceable evidence, system observations, policies, and validation results.

Transparency

Organizations should be able to selectively publish meaningful compliance and trust information without exposing sensitive infrastructure details.

Modular Architecture

Core functionality shall be separated into focused modules with defined responsibilities and interfaces.

Open-Source Infrastructure

The system shall be inspectable, extensible, and deployable without requiring dependence on a proprietary compliance platform.

Privacy and Data Minimization

ProofLayer shall collect only the information necessary to perform configured compliance and verification functions.

Human-in-the-Loop Governance

Automated evaluations, AI-assisted analysis, and policy decisions shall support human review where interpretation, remediation approval, risk acceptance, or audit judgment is required.

Framework Extensibility

The architecture shall support future compliance frameworks without requiring replacement of the core evidence and verification infrastructure.

Core Modules

Control Framework Engine

The Control Framework Engine shall provide machine-readable definitions for compliance controls, requirements, evidence expectations, validation logic, and control relationships.

The module shall support:

SOC 2 control mappings.
SOC 3 reporting support.
Trust Services Criteria mappings where applicable.
Control definitions and metadata.
Evidence requirements.
Validation rules.
Control ownership.
Review schedules.
Exceptions and compensating controls.
Control status tracking.
Versioned control definitions.

The engine shall allow organizations to adapt controls to their operational environment while preserving traceability between internal controls and applicable framework requirements.

Evidence Collection Engine

The Evidence Collection Engine shall continuously or periodically collect configured evidence from approved sources.

Supported evidence categories may include:

Authentication events.
Access control records.
Administrative activity.
Infrastructure configuration.
Deployment activity.
Change management records.
Security alerts.
Vulnerability findings.
Encryption configuration.
Backup activity.
Recovery tests.
Availability metrics.
Incident records.
Vendor and dependency information.

The module shall support:

Timestamping.
Source identification.
Evidence classification.
Evidence integrity validation.
Retention policies.
Access restrictions.
Evidence versioning.
Evidence provenance.
Redaction where required.

Evidence Archive

The Evidence Archive shall provide structured storage and retrieval for compliance evidence.

The archive shall support:

Immutable or tamper-evident storage options.
Cryptographic integrity verification.
Evidence retention policies.
Evidence expiration policies.
Access controls.
Search and retrieval.
Evidence export.
Redaction workflows.
Auditor access workflows.

Evidence records should maintain sufficient provenance to identify their source, collection time, processing history, and associated controls.

Continuous Control Monitoring

The Continuous Control Monitoring module shall evaluate configured controls against current or periodically collected system state.

The module shall support monitoring for:

Access management.
Multi-factor authentication enforcement.
Privileged account activity.
Encryption requirements.
Infrastructure configuration.
Logging availability.
Security monitoring.
Backup completion.
Recovery readiness.
Availability targets.
Unauthorized configuration changes.
Policy violations.

The module shall identify changes that may affect compliance posture.

Policy Evaluation Engine

The Policy Evaluation Engine shall evaluate machine-readable policies against evidence and system state.

The module shall support:

Policy definition.
Policy versioning.
Automated evaluation.
Scheduled evaluation.
Event-driven evaluation.
Exceptions.
Remediation recommendations.
Evaluation history.
Policy result provenance.

Policies shall be capable of supporting infrastructure, application, identity, data, and operational controls.

Infrastructure Drift Detection

The Infrastructure Drift Detection module shall identify changes between approved and observed system configurations.

The module shall detect potential compliance-impacting events such as:

Encryption being disabled.
Logging being disabled.
Unauthorized network exposure.
Privilege escalation.
Missing authentication controls.
Configuration changes outside approved workflows.
Changes to backup or recovery systems.

Detected drift shall be associated with relevant controls and evidence records where possible.

Compliance Posture Engine

The Compliance Posture Engine shall aggregate control results into an understandable representation of organizational compliance posture.

The module shall support:

Control status.
Evidence availability.
Validation history.
Open findings.
Exceptions.
Remediation status.
Historical trends.
Configurable scoring models.

Any score generated by the system shall be clearly identified as a ProofLayer assessment and shall not be represented as an official SOC audit result.

SOC 2 Evidence Package Generator

The SOC 2 Evidence Package Generator shall organize evidence and control information into structured packages suitable for audit preparation and review.

The module shall support:

Control-to-evidence mapping.
Evidence indexes.
Review histories.
Control descriptions.
Validation results.
Exception documentation.
Evidence export.
Time-period filtering.
Auditor-oriented summaries.

Generated packages shall be configurable to support different organizational environments and audit requirements.

SOC 3 Transparency Module

The SOC 3 Transparency Module shall support the publication of public-facing trust and compliance information.

The module may publish:

High-level compliance posture.
Public assurance information.
Availability metrics.
Security commitments.
Incident disclosures.
Transparency statements.
Verification status.

The module shall provide controls that prevent sensitive internal evidence or confidential infrastructure information from being exposed publicly.

ProofLayer-generated transparency information shall be clearly distinguished from an official SOC 3 report issued by an authorized independent auditor.

Public Trust Dashboard

The Public Trust Dashboard shall provide a human-readable interface for publishing selected trust and compliance information.

The dashboard may include:

Service availability.
Historical uptime.
Security status indicators.
Public incident information.
Compliance statements.
Verification timestamps.
Links to published reports.
ProofLayer verification information.

Organizations shall control which information is publicly visible.

Machine-Readable Compliance Endpoint

ProofLayer shall support the .well-known/compliance endpoint as a machine-readable compliance discovery mechanism.

The endpoint shall provide structured compliance metadata that may include:

Organization identity.
Supported compliance frameworks.
Publicly available reports.
Verification status.
Relevant audit dates where publication is authorized.
Availability information.
Security status indicators.
ProofLayer verification metadata.
Update timestamps.
Cryptographic verification information.

The endpoint shall be designed to avoid exposing confidential evidence, sensitive infrastructure information, or personal data.

The .well-known/compliance implementation shall support versioning to enable future evolution of the format.

Verification and Integrity Module

The Verification and Integrity Module shall support cryptographic methods for establishing evidence integrity and provenance.

The module shall support:

Evidence hashing.
Signed records.
Signed manifests.
Timestamp verification.
Integrity validation.
Tamper detection.
Verification of published compliance metadata.

The module may integrate with compatible signing and verification systems.

Incident and Exception Management

The Incident and Exception Management module shall provide structured workflows for events that affect compliance controls.

The module shall support:

Incident records.
Control exceptions.
Risk acceptance.
Compensating controls.
Remediation plans.
Review dates.
Resolution records.
Historical tracking.

The module shall support human approval workflows for decisions that require organizational or professional judgment.

Vendor and Dependency Risk Module

The Vendor and Dependency Risk Module shall track external services, vendors, dependencies, and other third-party components relevant to organizational compliance.

The module shall support:

Vendor inventories.
Dependency inventories.
Security documentation.
Compliance documentation.
Risk classification.
Review schedules.
Incident tracking.
Dependency changes.
Evidence association.

Disaster Recovery Verification

The Disaster Recovery Verification module shall support evidence collection and validation for recovery readiness.

The module shall support:

Backup verification.
Restoration testing.
Recovery test records.
Availability monitoring.
Failover testing.
Recovery objectives.
Test scheduling.
Historical results.

The system shall distinguish between planned tests, successful verification, failed tests, and untested controls.

Compliance Reporting Engine

The Compliance Reporting Engine shall generate configurable reports for internal teams, auditors, customers, and public transparency workflows.

The module shall support:

Internal compliance reports.
Control status reports.
Evidence summaries.
Audit preparation reports.
Exception reports.
Historical trend reports.
Public transparency reports.

Reports shall identify their source data, generation time, applicable period, and relevant limitations.

Optional Plugin Modules

AI Compliance Analysis Plugin

The AI Compliance Analysis Plugin may analyze evidence, telemetry, policies, and documentation to assist organizations with compliance operations.

The plugin may support:

Control mapping assistance.
Gap identification.
Documentation drafting.
Evidence classification.
Remediation suggestions.
Audit preparation assistance.
Natural language queries.

AI-generated results shall be identified as recommendations or analysis rather than authoritative audit conclusions.

Multi-Framework Mapping Plugin

The Multi-Framework Mapping Plugin may map shared controls and evidence to additional frameworks.

Potential frameworks may include:

ISO/IEC 27001.
Privacy requirements.
Industry-specific security requirements.
Regional regulatory requirements.

The plugin shall preserve traceability between source controls, evidence, and framework mappings.

Cloud Provider Integration Plugins

Cloud Provider Integration Plugins may connect ProofLayer to supported infrastructure providers and services.

Plugins may collect approved evidence relating to:

Identity management.
Configuration state.
Logging.
Encryption.
Storage.
Networking.
Backup systems.
Security monitoring.

Each integration shall define its permissions and collected data.

Identity Provider Integration Plugins

Identity Provider Integration Plugins may connect ProofLayer to authentication and identity systems.

Plugins may support:

User inventories.
Privileged access review.
Multi-factor authentication verification.
Account lifecycle events.
Access policy evidence.

Security Tool Integration Plugins

Security Tool Integration Plugins may connect ProofLayer to external security systems.

Potential integrations may include:

Vulnerability management.
Runtime monitoring.
Endpoint security.
Security information and event management.
Incident management.

Infrastructure-as-Code Integration Plugins

Infrastructure-as-Code Integration Plugins may evaluate infrastructure definitions before and after deployment.

Plugins may support:

Policy validation.
Configuration analysis.
Change tracking.
Drift detection.
Deployment evidence.

Public Registry Plugin

The Public Registry Plugin may allow organizations to publish selected ProofLayer verification metadata to a public registry.

The plugin shall support:

Opt-in participation.
Organization verification.
Signed records.
Historical status.
Revocation or status changes.

Participation shall not expose confidential compliance evidence.

Compliance Badge Plugin

The Compliance Badge Plugin may generate embeddable indicators that display selected ProofLayer status information.

Badges shall clearly distinguish:

ProofLayer validation.
Internal compliance assessments.
Third-party audit results.
Official assurance reports.

Auditor Collaboration Plugin

The Auditor Collaboration Plugin may provide controlled access to evidence packages and review workflows.

The plugin may support:

Read-only access.
Evidence requests.
Review notes.
Export workflows.
Access expiration.
Activity logging.

Security Requirements

ProofLayer shall implement security controls appropriate to its role as a system that may process sensitive compliance information.

The system shall support:

Authentication.
Authorization.
Role-based or policy-based access control.
Encryption in transit.
Encryption at rest where configured.
Audit logging.
Secret management.
Data retention controls.
Evidence access restrictions.
Secure plugin permissions.

Security-sensitive operations shall be traceable through audit records.

Privacy Requirements

ProofLayer shall support privacy-preserving evidence collection and reporting.

The system shall provide mechanisms for:

Data minimization.
Redaction.
Pseudonymization where appropriate.
Retention policies.
Deletion workflows where legally and operationally appropriate.
Restricted access to sensitive evidence.
Separation of public and private compliance data.

Interoperability

ProofLayer shall provide documented interfaces that enable integration with external systems.

Interfaces may include:

APIs.
Webhooks.
Event streams.
Machine-readable exports.
Evidence manifests.
Policy definitions.
Plugin interfaces.

Interfaces shall support versioning to maintain compatibility as the project evolves.

Governance

ProofLayer shall support transparent development and governance.

Changes affecting:

Control definitions.
Evidence interpretation.
Public compliance schemas.
Cryptographic verification.
Security architecture.
Plugin interfaces.

should be documented and subject to appropriate review.

Specification Branding License (SBL)

Standard

Fully AGPL-3.0+ compliant system
Copyleft enforced for network deployments
Required attribution:
- Roxanne Ardary
- https://www.roxanneardary.com/

Optional

Specification Branding License (SBL)
- Attribution-free commercial deployment
- Pricing based on scale, usage, and deployment scope
- https://roxanneardary.com/prooflayer/

License & Notice Requirements

ProofLayer is released under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).
By contributing to this project, you agree that your contributions will also be released under this license.

Please note the following:

All contributions must comply with the AGPL-3.0+ terms.
Under Section 7 of the license, all redistributions, forks, and derivative works must preserve attribution to:
Roxanne Ardary and roxanneardary.com.
ProofLayer specifications are free to use with attribution. A Specification Branding License can be negotiated upon request.
The project’s notice.md file tracks attribution requirements and contributor acknowledgments.
Any update that adds new contributors or modifies attribution should also update notice.md.
When submitting a pull request, ensure that any new files maintain the attribution headers where applicable.
Network-deployed versions of this software must also remain fully AGPL-3.0+ compliant, including exposure of source code modifications when applicable under the license.

For full legal details, please refer to the AGPL-3.0+ license and the project’s notice.md file.

Notice – ProofLayer

Attribution Requirement: Under Section 7 of the AGPL 3.0+ license, all redistributions, forks, and derivative works, including network-deployed versions of this project, must provide attribution to Roxanne Ardary and roxanneardary.com.

Contributors

This file tracks contributors and their specific contributions to the project.

Roxanne Ardary, roxanneardary.com – March 14, 2026
Created the repository for ProofLayer. Developed the open-source continuous SOC 2 and SOC 3 compliance infrastructure, including automated evidence collection, transparency dashboards, and the .well-known/compliance standard.
[Add other contributors here] – [Date]
[Describe contribution in one sentence]

License – ProofLayer

This repository is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

Key Points:

You are free to use, modify, and distribute the code.
All redistributions, forks, and derivative works or network-deployed versions must also be licensed under AGPL-3.0+ and provide attribution to Roxanne Ardary and roxanneardary.com as required under Section 7 of the license.
The software is provided “as is,” without warranty of any kind.

For the full license text, see GNU AGPL-3.0 License.