Certify before you commit.
QISTAS is a deterministic certification layer between operational decision systems and execution. It determines what is admissible now, under which evidence and constraints, and when that certification must be withdrawn or recomputed.
Forecast / Optimize / Plan
Existing stack
QISTAS
Certification plane
Certified commitment
Within bounds
Execution
Existing stack
01Position
QISTAS does not replace your optimizer.
The optimizer asks: what is the best action? QISTAS asks: what can the organization legitimately and operationally commit to now, under the evidence currently available?
It sits as an independent certification plane. Forecasting systems, optimizers, market engines, planning engines, VPPs, smart-charging and dispatch systems stay in place.
- Your stack
Forecasting estimates.
- Your stack
Optimization selects.
- Tajalli
QISTAS certifies admissibility.
- Your stack
Execution acts.
02Decisions
The proposal is an input. The certificate is the commitment.
When a proposal exceeds what current evidence supports, QISTAS does not argue with the optimizer. It certifies the admissible portion and gates the commitment to it.
Illustrative commitment
CLAMP- Optimizer proposes
- 4.2 MW
- QISTAS certifies
- 2.9 MW
- Approved commitment
- 2.9 MW
- ALLOW
The proposal is admissible as stated.
- CLAMP
Only a certified portion is admissible.
- REJECT
No admissible commitment exists now.
- RECERTIFY
A boundary was crossed. The prior certificate is withdrawn.
03Scope
Every certificate answers seven questions.
- 01What is admissible now
- 02Under which evidence
- 03Under which constraints
- 04For how long the certification remains valid
- 05Which boundary invalidates it
- 06When it must be withdrawn
- 07When a new state requires recertification
04Architecture
From evidence to a gated, replayable commitment.
- 01Evidence
- 02Canonical Source State
- 03Deterministic Certification
- 04Validity Boundary
- 05Boundary Monitoring
- 06Withdrawal / Recertification
- 07Portfolio Certification
- 08Commitment Gate
- 09Audit / Replay
05Capabilities
Certification infrastructure, not another model.
- 01
Canonical Source State
Heterogeneous telemetry, schedules and declarations are normalized into one explicit, versioned state before anything is certified.
- 02
Deterministic Certification
Admissibility is computed as a deterministic function of state and policy. No invented evidence, no sampling in the decision path.
- 03
Validity Boundary
Each certificate states the conditions under which it holds. Validity is explicit, not assumed from elapsed time alone.
- 04
Rolling Recertification
When monitored evidence crosses a boundary, the certificate is withdrawn and the new state is deterministically recertified.
- 05
Portfolio Certification
Asset-level certificates are composed into a conservative portfolio-level certificate. The portfolio never claims more than its assets support.
- 06
Commitment Gate
Bids, offers, schedules and dispatch instructions pass only within certified bounds. Proposals beyond them are clamped or rejected.
- 07
Audit & Replay
Any certificate can be reconstructed from its recorded state, policy version and evidence lineage.
- 08
Evidence Ledger
Immutable decision lineage with cryptographic certificate identity. Every certificate is hashed over the content that produced it.
- 09
Policy Versioning
Certification rules are versioned releases. Every certificate references the policy version under which it was issued.
- 10
Integration Adapters
Client-specific adapters map local formats into canonical state. The adapter changes per environment; the deterministic core does not.
06Integration
Attaches to the stack you already run.
Integration targets are scoped per engagement. Shadow studies can begin from file exports before any live interface is built.
- REST APIs
- Event streams
- Kafka-compatible systems
- CSV / SFTP for shadow studies
- Enterprise APIs
- OCPP / OCPI where relevant
Listed interfaces are supported integration patterns, confirmed per deployment.
07Selected validation results
First validated vertical: distributed energy flexibility.
QISTAS was validated first against distributed flexibility use cases, including EV flexibility. Energy is the first validation domain of the architecture, not the boundary of it.
QISTAS
Fresh unseen validation
Frozen decision rules evaluated on data not used during calibration.
- external publication compression
- 98.7248%
- decision-relevant status transitions captured
- 23 / 23
- ADMISSIBLE → INFEASIBLE transitions captured
- 17 / 17
- downward overstatement events
- 0
- stale publications
- 0
- deterministic replay
- 26 / 26
Results shown are from controlled public-data validation and shadow evaluation. They are not customer-production performance claims.
QISTAS
Portfolio validation
Conservative composition of asset-level certificates into portfolio commitments.
- of internally admissible capacity-time preserved by the conservative certification layer
- 95.61%
- portfolio overstatement events
- 0
- deterministic portfolio replay in the evaluated dataset
- 100%
Results shown are from controlled public-data validation and shadow evaluation. They are not customer-production performance claims.
08QISTAS questions
What evaluation teams ask about QISTAS.
Does QISTAS replace forecasting or optimization?
No. Forecasting estimates what may occur. Optimization determines a preferred decision. QISTAS determines what can currently be certified as admissible under the available evidence and governing constraints.
These functions are complementary.
What invalidates a QISTAS certification?
Each certification carries explicit validity conditions: the evidence it was derived from and the operational boundaries within which it holds.
A certification is invalidated when monitored evidence crosses one of those boundaries, when required evidence stops arriving, or when the governing policy version is replaced. It is then withdrawn and the current state is evaluated again.
What happens when evidence becomes stale?
Staleness is treated as a boundary in its own right. Evidence older than its permitted age no longer supports the certification built on it.
Depending on configuration, QISTAS withdraws the affected certification or reduces it to what remaining evidence still supports. It does not continue publishing a certification on expired evidence.
Can QISTAS operate in Shadow Mode?
Yes. In Shadow Mode, QISTAS consumes the same proposals and evidence as the production workflow and computes certifications in parallel, without gating any commitment.
Its decisions are then compared with what was actually committed. Shadow studies can begin from historical or file-based exports.
How is a QISTAS decision replayed?
Each certification is recorded with its input evidence, canonical state, policy version, engine version and validity boundaries.
Replay re-executes the certification from those recorded inputs. Because the decision layer is deterministic, the replayed certification must match the original; any difference is treated as a defect.
Enterprise enquiries
Certify before you commit.
Start with a shadow study on historical or live exports. No change to your existing optimization stack is required.