Trust through evidence.
Apeiris is built on a simple premise: important claims should be inspectable, attributable, and independently verifiable. This page separates what can be verified today from the operating controls we are formalizing and the hosted platform capabilities that remain planned — and it lets you verify the corpus itself, right here, without taking our word for anything.
This is a factual trust view, not a certification badge. The public knowledge layer is live. The runtime platform remains a prototype. Readiness work does not equal an independent attestation.
See the boundaries →What exists now, what is being formalized, and what comes later.
“Current” describes a capability visible or independently testable today. “In progress” describes operating-program work that is not yet an attestation. “Planned” describes the future hosted platform.
Published corpus integrity
Artifacts are content-addressed, pinned in a signed manifest, and recomputable in the browser against the published trust anchor.
CurrentMinimal-data website
The public site is static, has no accounts, and its interactive assurance tools process user selections locally in the browser.
CurrentSecure-development validation
Build-blocking SAST and dependency checks, SBOM generation, multi-round LLM-assisted adversarial review, and seeded fuzz testing are documented for the public knowledge layer and tooling.
Evidence-backedSecurity program formalization
Policies, inventories, risk records, control ownership, evidence collection, and SOC 2 Type I readiness artifacts are being formalized.
In progressSecurity reporting
Apeiris publishes a security.txt and accepts responsible reports at security@apeiris.ai.
CurrentSOC 2 Type I
The intended first step is a scoped Type I examination after the system boundary, control design, evidence, and readiness review are complete.
PlannedFour layers of assurance — and where Apeiris stands on each.
Trust is broader than "the signature checks out." A signature proves integrity; it says nothing about whether a mapping is correct or a service is reliable. Here are the four layers, kept separate — with an honest read of each.
Integrity
Strongest todayAre these the exact bytes Apeiris published? An Ed25519 signature over the JCS-canonical manifest, and every artifact's SHA-256 pinned — recompute both in your browser.
Provenance
Strong todayCan the claims be traced to sources and editorial decisions? A registry of normative sources, captured primary-text anchors, a review ledger, and per-mapping fit / basis / relationship.
Semantic quality
DevelopingWere the mappings and controls reviewed and tested? Adversarial verification and a cross-vendor validation study are in place; a gold benchmark and broader external review are still being built.
Operational assurance
Future platformIs the hosted service secure, and are empirical outputs reliable? This applies to the platform in development — not to the published corpus.
Apeiris is strongest in layers 1 and 2, honest that layer 3 is developing, and clear that layer 4 belongs to the future platform. Disclosing that increases trust — it doesn't reduce it.
Everything above is a claim. Don’t trust it — verify it.
Recompute every hash, validate the Ed25519 signature, and inspect the evidence chain — entirely in your browser, against open artifacts, with no Apeiris server trusted in the loop — and reproducible out-of-band with your own tools if you'd rather not trust the in-browser verifier either. Integrity and provenance are testable without trusting an Apeiris assertion.
Each published artifact is identified by its SHA-256 digest.
The digest and release metadata are pinned in the integration manifest.
The manifest is canonicalized using RFC 8785 JSON Canonicalization Scheme.
The canonical manifest is signed with an offline Ed25519 key.
Your browser fetches and hashes the same artifacts, below.
A mismatch means the fetched copy is not the release Apeiris signed.
No server is trusted at verification time: your browser fetches the open artifacts, recomputes every SHA-256, and checks the manifest’s Ed25519 signature against the published public key. The signature is checked automatically on load. A valid signature proves the bytes are authentic and unchanged since we published them — it is not a claim that a control, mapping, or interpretation is semantically correct or operationally effective.
- Client-side
- Deterministic
- Cryptographically verifiable
- No server trusted at verify time
- Open artifacts
- Reproducible by anyone
A mismatch on the signature or any checksum means the copy you fetched is not what Apeiris signed — treat it as fail-closed and stop. Prefer to reproduce it out-of-band? Run it with a curl one-liner or Node’s built-in crypto →
Engineering assurance is evidence, not a guarantee.
On July 10, 2026, Apeiris completed four security-testing layers for the public knowledge layer and its deterministic tooling. Confirmed defects were dispositioned, remediated where required, and protected by regression tests. The work was internal, not an independent penetration test.
Deterministic SAST
Semgrep runs in CI over the declared JavaScript, MJS, client-side JavaScript, and Python scopes using pinned rulesets.
PassedDependency audit & SBOM
npm audit, a reproducible CycloneDX SBOM, and generated third-party inventory are checked as part of the development workflow.
PassedLLM-assisted secure code review
Four rounds covered trust-core, SDK, overlays, build pipeline, MCP surfaces, client JavaScript, cryptography, and the local HTTP prototype. Candidate findings were manually reproduced and dispositioned.
Passed with observationsSeeded fuzz testing
A reproducible harness exercised critical untrusted-input parsers and fail-closed invariants across approximately 6,000 generated and edge-case inputs.
Passed with observationsBounded assurance
Testing is scoped, internally performed, and complementary to deterministic scanning and human review. It does not guarantee the absence of vulnerabilities.
Explicit boundaryWe test our own claims
Apeiris evaluates its engineering practices against the same evidence and fail-closed concepts it publishes, while keeping alignment separate from compliance or attestation.
DocumentedCompany security is separate from corpus integrity.
Cryptographic publication integrity and engineering testing are not substitutes for access management, endpoint security, incident response, resilience, or vendor governance.
Access control
Document unique identities, MFA coverage, least privilege, privileged access, service accounts, recovery methods, and periodic access review.
Validation requiredMonitoring & response
Define the logs Apeiris owns, provider telemetry, alerting, incident severity, escalation, communication, and post-incident review.
Program designBackup & recovery
Define recoverable assets, repository and artifact backups, DNS recovery, signing-key recovery, RTO/RPO, and restoration testing.
Validation requiredVendor risk
Inventory hosting, source control, email, registrar, password management, endpoint, model, and future platform providers.
Inventory requiredRisk & control ownership
Assign owners, document risks, record exceptions, map controls to evidence, and review claims before they become public.
In progressCoordinated reporting
The current disclosure scope covers the public website and integration endpoints. Internal systems and the non-public platform layer are excluded.
View scopeThe current service is intentionally data-light.
The privacy posture shown here applies to the public knowledge layer and browser-based tools. It must be reassessed before any hosted product stores accounts, prompts, evidence, or tenant data.
The trust center should demonstrate the Apeiris model.
Public claims should ultimately render from structured records with scope, owner, status, review date, evidence references, and an explicit public/private boundary.
“Published artifacts are independently verifiable.”
The statement is useful only when its implementation, evidence, limitations, and review history can be inspected.
A bounded, reviewable public statement.
The process or technical mechanism intended to make the claim true.
Configuration, test, record, artifact, or independent result.
Owner, verification date, exceptions, and next review.
Readiness is not attestation.
Apeiris should publish progress without converting planned controls into claims. SOC 2 should appear as a program milestone only after the underlying artifacts and operating reality support it.
Document the current public layer, company systems, exclusions, and future hosted platform separately.
Policies, procedures, ownership, evidence sources, risk decisions, and compensating controls.
Access, changes, assets, vendors, risks, recovery, incidents, scans, and reviews.
Complete readiness, remediate design gaps, engage the auditor, and issue the report.
One brand. Distinct operating boundaries.
This separation prevents public corpus capabilities from being mistaken for hosted-service controls or customer commitments.
Public knowledge layer
Static website, public corpus, source references, graph, browser-based analysis tools, signed manifests, and read-only integration artifacts.
ProductionSupporting business systems
Source control, hosting, DNS, email, development endpoints, credentials, backups, security records, and vendors must be inventoried for the audit boundary.
To be documentedHosted runtime platform
Customer authentication, tenant isolation, hosted evidence ingestion, runtime enforcement, databases, platform telemetry, and contractual availability.
Prototype / plannedPublish useful summaries. Protect sensitive evidence.
The document library links to current public resources and reserves clear places for artifacts that should be created as the security program is formalized.
Privacy statement
Current collection, browser processing, hosting, contact, and change practices.
ViewTerms of use
Open corpus licensing context, beta limitations, and clear non-certification language.
ViewResponsible disclosure
Security contact, scope, testing expectations, and coordinated reporting path.
ViewSecurity overview
Architecture, access, secure development, vulnerability management, monitoring, incident response, and resilience.
CreateResponsible AI statement
Where AI is used, human review, source fidelity, model providers, limitations, and correction practices.
CreateAssurance package
SOC 2 report, penetration-test report, detailed diagrams, control matrix, and supporting evidence when available.
GatedQuestions, diligence, and security reports.
Use the channel that matches the request. Do not send secrets, credentials, exploit payloads, or sensitive customer data in an initial email.
Check before relying
Use the published verifier, source references, machine-readable artifacts, and explicit review status.
Verify now