Integration
Designed to sit between evidence and commitment — not replace the systems around them.
Qistas reads what your systems already produce, maps it explicitly into a canonical assurance model and returns structured results.
Client systems
- Optimizer
- VPP
- EMS
- DERMS
- Trading
- Portfolio systems
- Telemetry infrastructure
Qistas integration layer
Assurance outputs
- Assurance API
- Events
- Audit records
01Flexible input mapping
Your data does not need to look like ours.
Enterprise systems describe the same things differently. Qistas accepts your evidence through explicit adapters and mappings into its canonical assurance model.
- Different field names
- Different units
- Different schemas
- Different asset identifiers
- Different event models
- Client data
- Mapping / adapter
- Canonical evidence
- Qistas assurance
Mappings are explicit, versioned and auditable. Semantic ambiguity is resolved with your team — not guessed by AI.
02Integration patterns
Adapter-based integration architecture.
- 01
REST API
Submit proposed commitments and receive assurance results.
- 02
File & batch ingestion
Structured exports for shadow studies, before any live interface.
- 03
Event-driven integration
Evidence and obligation changes processed as they occur.
- 04
Adapters & reusable mappings
Per-environment adapters into the canonical model; mappings are versioned and reused.
- 05
Machine-to-machine authentication
Scoped credentials per integrating system.
- 06
Idempotent processing
Repeated submissions do not create duplicate results.
- 07
Audit records
Every result is preserved with its inputs and versions.
- 08
Charging-domain adapters
OCPP / OCPI adapter contracts where relevant to the scope.
Patterns are confirmed per deployment. No production-certified interoperability with specific protocols or vendors is claimed.
03Enterprise trust
Built to be examined by risk, control and security teams.
- 01
Traceable operations
Each assurance result references its evidence, obligations, policy version and software version.
- 02
Versioned records
Policies and results are versioned, so history is not rewritten by later changes.
- 03
Content hashes
Decision records can be identified by cryptographic hashes of their content.
- 04
Scoped access
Machine credentials and user roles limited to what each integration needs.
- 05
Data minimization
Only the evidence needed for the commitment being assured.
- 06
Deployment options
Deployment patterns, including customer-controlled environments, are scoped per evaluation.
Detailed security and deployment architecture available during enterprise evaluation.
04Enterprise questions
Shadow Pilot & integration
What if our data model is different?
Qistas uses explicit adapter and mapping layers to translate your field names, units, schemas, identifiers and event models into its canonical assurance model.
Mappings are explicit, versioned and auditable. They are agreed with your team, not inferred by AI.
Does Tajalli need access to all of our data?
No. The architecture follows data minimization.
It requires the evidence needed for the specific decision being assured or authorized, not unrelated business or personal information.
Can Tajalli run inside our own infrastructure?
Tajalli is architected for enterprise deployment patterns, including customer-controlled environments.
Available deployment options are confirmed during evaluation scoping.
Does Qistas expose its proprietary mathematical core?
No. Enterprise users receive traceable decision evidence — inputs, steps, reasons and results — without disclosure of proprietary theory or protected internal mathematics.
Enterprise enquiries
Keep your optimizer. Add independent assurance.
Evaluate Qistas against your existing commitments in a read-only Shadow Pilot before making any operational change.