SSolarc Labs

Private-beta security boundaries

Security claims should be as narrow as the product that implements them.

The controls below describe published product boundaries. They are not a blanket certification, penetration-test result, enterprise SLA or claim that every product shares one architecture.

Customer-specific hosting, identity, retention, backup, network exposure and incident requirements are confirmed in the relevant product or written scope.

Published controls

Read the control and its boundary together.

The useful question is not whether a security word appears on the page. It is which product, data path and workflow state that control actually covers.

01

1. Product-specific security boundaries

Security claims are scoped to the product that actually implements the control.

  • AccessGuard and RevenueGuard use guarded public-target browser/network paths rather than unrestricted browsing.
  • DomainGuard checks public DNS and explicit operator-supplied DKIM selectors; it does not mutate DNS automatically.
  • ClientVault and InvoiceGuard keep explicit human review/decision gates instead of silently approving sensitive workflows.
  • InvoiceBatch FR has no public invoice-upload portal; its product page, checkout and controlled intake remain separate, with product-specific privacy and data-processing terms.
02

2. Encrypted application state

The current Guard products use AES-GCM encrypted persistence for their sensitive app-owned state.

  • AccessGuard encrypts baseline/monitor state used for accessibility regression comparisons.
  • RevenueGuard encrypts run history and bounded failure evidence.
  • DomainGuard encrypts monitor and aggregate-report persistence.
  • ClientVault and InvoiceGuard encrypt stored document/source evidence before persistent storage.
03

3. Guarded execution paths

Network and parser boundaries are designed to fail closed rather than accept arbitrary execution.

  • AccessGuard and RevenueGuard validate targets and use DNS-pinning-safe browser/proxy controls for public web execution.
  • RevenueGuard exposes a bounded declarative journey DSL and does not provide arbitrary JavaScript/eval.
  • DomainGuard isolates bounded aggregate-report parsing and never guesses DKIM selectors.
  • InvoiceGuard runs the pinned invoice extractor through an isolated Python process; client requests cannot select arbitrary extractor code.
  • InvoiceBatch FR validates bounded inputs through a local-first operator runtime, loopback-only Saxon and local CodeDB; deterministic blockers cannot be waived into a clear result.
04

4. Real malware-scanner gates where files are accepted

ClientVault and InvoiceGuard require a real scanner in production/release verification.

  • Their production/release path requires a command-line malware scanner that detects the EICAR test fixture.
  • The canonical release gate does not replace that requirement with a fake scanner.
  • Allowed upload formats and size bounds remain product-specific and are documented in each product repository.
05

5. Human review remains explicit

Automation evidence is not silently promoted into legal, financial or compliance decisions.

  • AccessGuard automated findings explicitly require manual review and do not certify WCAG or legal compliance.
  • ClientVault acknowledgement is workflow evidence, not a claim of legally sufficient electronic signature.
  • InvoiceGuard clean extraction ends at ready_for_review and still requires one explicit approve/reject decision.
  • InvoiceBatch FR is a technical preflight with human-reviewed evidence; it is not legal or tax advice, a Plateforme Agréée, certification or acceptance guarantee.
06

6. Local release evidence

Customer handoff is gated on the same product release proof used by the operator.

  • Each Guard product documents a canonical local/Docker release path rather than relying on GitHub Actions as release evidence.
  • A formal passing release requires artifacts/release-evidence.json with ok=true on the delivery environment.
  • InvoiceBatch FR commercial delivery requires its exact release gate and auditable evidence artifact to pass on the operator environment before customer material is processed.
  • Security questions and vulnerability reports currently route to the monitored contact inbox: enoch@solarclabs.com with SECURITY in the subject.
Reporting path

A real contact route matters more than a trust badge.

Legal entity
SOLARC GOODS LIMITED
Company Registration No.
16998296 · England & Wales
ICO reference
ZC165202
Security reports
enoch@solarclabs.com · subject: SECURITY

Scope boundary.

A product pilot is not a security certification. Review the specific product page and written scope before introducing production or sensitive data.

Product boundaries Contact Solarc Labs