Security and governance

Forecasting access should follow the same boundaries as operating data.

Openfluid is being designed around least-privilege access, source lineage, numerical controls and human approval. This page describes the intended security posture and current limitations; it does not claim certifications that have not been completed.

Request a security discussion →See platform controls

No unearned certification claimsRole and outlet scopeForecast version and lineage

IdentityUser and role

ScopeOutlet and capability

DataSource and field

ActionView, export, approve

Transparency

Current assurance status.

Openfluid does not currently claim SOC 2, ISO 27001 or another independent product certification on this prototype website. Security requirements, hosting model, subprocessors, retention and contractual commitments must be reviewed before production use.

Design intent

Controls the product should implement

Tenant isolation, encryption, scoped access, audit logs, secrets management, backups, vulnerability management and incident response.

Evidence required

Controls a customer should verify

Architecture, policies, test records, provider configurations, penetration testing, data-flow diagrams and contractual commitments.

Control areas

Security must cover the whole decision path.

01 · IdentityAuthentication and session controlSSO, MFA, invitation policy, session expiry and account recovery.

02 · AuthorisationRole and outlet boundariesMember, manager and admin capabilities; consolidated data only where permitted.

03 · IngestionRead-only source accessScoped credentials, network controls, secret rotation and source-specific auditability.

04 · StorageTenant separation and encryptionDocumented data locations, retention, backups and deletion workflows.

05 · ForecastingVersion, cutoff and numerical integrityModel version, input window, grouped-total conservation and exception state.

06 · ActionsHuman approval and audit trailOriginal recommendation, override, reason, user and timestamp.

Model controls

AI governance is more than a privacy sentence.

Grounded retrieval

Forecast Chat should call approved data services and show scope. It should not rely on hidden prompt context for material numbers.

Deterministic calculations

Totals, gaps, recipe multiplication and business-rule calculations should run outside the language model and be testable directly.

Prompt and model change control

Changes that affect routing, explanation or output format need versioning, evaluation and rollback.

Data-use commitments

Training, retention and subprocessor use must be stated in final product documentation and contracts, not inferred from generic provider language.

FAQ

Questions for a security review.

Where is customer data hosted?

The deployment architecture and region have not been fixed by this prototype. A production proposal must identify cloud provider, region, backups and subprocessors.

Is customer data used to train models?

This website should not make a blanket claim until the application architecture, model providers and contracts establish the exact data-use policy.

Can access be restricted by outlet?

That is an intended product control. Production validation should test API, export, chat and cached-result paths, not only the visible navigation.

How are security incidents handled?

An incident response process, notification terms and escalation contacts must be documented before enterprise deployment.

Review evidence before trusting a badge.

A security discussion should cover architecture, data flow, providers, access, retention, testing and contractual commitments.

Start a security review →