QUESTIONS,ANSWEREDDIRECTLY.

A product company building production-grade AI systems for environments where a wrong answer is expensive. We build our own architecture, called Barion Core, and deploy our own products on top of it. PSX Invest is live in the Pakistan Stock Exchange today.

No. We do not sell development hours, staff augmentation or AI strategy documents. We deploy and co-build controlled intelligence systems using our own architecture, guardrail patterns and production experience. The difference is that we own and operate what we build rather than handing over code and leaving.

Systems that take signals from several sources, generate and rank options, enforce constraints, route anything consequential to a human for approval, and record the whole chain so it can be reviewed later. Applied to markets that is PSX Invest. Applied to clinical decisions and operations it becomes Clinical Insight Engine and Barion Agents, neither of which is available yet.

Pakistan, working remotely. Our first product serves the Pakistan Stock Exchange, and the architecture is not geographically specific.

One. PSX Invest is operating in production with real users and has a free plan. Clinical Insight Engine is in development and Barion Agents is specified but not yet built. We label product status on every page and do not present unreleased products as available.

Live means operating in production today with real users. In development means being designed and built, not available for deployment. Coming soon means specified and in progress, not yet available. We do not blur these categories.

PSX Invest is a Barion AI product, not a client project. Barion Core runs the ingestion, indicator processing, ranking and confidence calibration; PSX Invest is the surface traders work in. We use it as evidence that we can take an intelligence system to production and keep it running, because it is the only honest form of proof we have.

No. It publishes a call with an entry range, a target, a stop and the indicators behind it, and then stops. It has no route to the market and places no orders. Every entry and exit is a manual decision made by the trader in their own broker account.

Yes, and that is the main route we are interested in. The pattern is that you bring the domain expertise, the data access, the business rules and decision ownership, and we bring the architecture, guardrail patterns, observability and product engineering. That path is described under Build with Barion.

No. It is in development, has not been clinically validated, and is not available for patient care. It does not diagnose and does not give independent medical advice. We make no claim of regulatory approval or clearance. Any deployment would require the relevant assessment with the deploying institution before use, and that work has not been done.

The shared architecture beneath every Barion AI product. Four layers carry a decision from raw sources to a recorded outcome: data and context, reasoning and optimisation, policy and guardrails, and actions and delivery. Logging, observability, evaluation, monitoring and feedback run across all four rather than sitting at the end.

No, and that is deliberate. Barion Core treats a model as a replaceable component behind an orchestration layer, alongside deterministic rule engines for the parts that must not be probabilistic. Models change, prices change and providers deprecate things, so no single external provider should be load-bearing for a system that has to keep working.

In code and configuration, outside the model. Permissions, constraints, validation and confidence thresholds are evaluated after options are generated and before anything is delivered or acted on. Instructions inside a prompt are a request a model may or may not honour; a policy check it cannot reach is a boundary.

Every recommendation carries the reasoning that produced it, and the record captures what the system received, what it concluded, which rules were applied, what it proposed, who approved it and what happened. The test we apply is whether one decision from a month ago can be reconstructed end to end from the record alone.

Through APIs, webhooks, data pipelines, product interfaces, approval systems and reporting layers. We do not publish a catalogue of pre-built connectors, because that would imply integrations we have not written. Connectors are built for the sources a specific deployment needs, and the effort involved is assessed rather than assumed.

Repeated decisions that are financially, clinically or operationally significant, need data from more than one source, must be explainable afterwards, have constraints the system must never violate, usually need human approval, and have to run continuously rather than once. If the consequence of being wrong is low, a simpler tool will serve you better and cost far less.

A narrow version of the system running against real data with guardrails already enforced, measured against success criteria agreed before it starts. It is deliberately small. A pilot on synthetic data proves very little, and a pilot without agreed criteria cannot fail, which makes it useless as evidence.

We do not quote a standard duration, because the honest answer depends on how ready the data and the decision are when we start. Whether data access already exists, whether constraints are written down and whether a decision owner is named change the timeline more than scope does. We scope it after the data and constraint assessment rather than promising it beforehand.

Per engagement, after scoping. We do not publish packages or rate cards because scope, data volume, integration surface and operating commitment differ too much between engagements for a published number to be meaningful.

You own your data, always. Ownership of the resulting product or system is agreed explicitly before work starts rather than left to be discovered later. Barion Core itself remains ours, since it is the shared architecture every product runs on.

Enough to make the decision the system is meant to support, which is established during the data and constraint assessment rather than requested up front. We would rather find out early that the necessary data does not exist or is not reliable than build something on top of that assumption.

No. We do not place engineers into your team by the month. If what you need is additional development capacity, a good software firm will serve you better and charge you less.

Your team owns the domain, the business rules and the decision. We own the intelligence architecture and the engineering around it. In practice that means your subject-matter experts validate what the system produces, and your operators feed back what actually happened once it runs.

None that we are claiming. We would rather say that plainly than list a certification we are working towards as though it were held. If a formal certification is a requirement for your organisation, raise it early so we can be honest about whether we can meet it in your timeframe.

Data handling, retention periods, residency and access requirements are assessed during deployment design and agreed with your organisation before anything is deployed. They differ enough between domains and jurisdictions that a single blanket answer here would be misleading.

Deployment model is one of the things assessed during deployment design. Rather than promise on-premise or private-cloud deployment generically, we would rather understand your constraints first and tell you honestly what is and is not practical.

It should already have stopped. Systems are built so that low confidence, a breached constraint or an unmapped case leads to escalation rather than action, and consequential actions sit behind human approval. When something does go wrong, the audit trail shows what the system received, what it concluded, which rules applied and who approved it, which is what makes a real post-mortem possible.

A named human. Our systems rank, explain and recommend; a person with the authority to do so decides. That is a design position, not a disclaimer, and it is why approval gates sit on the critical path rather than alongside it.

Not without an explicit written agreement covering it. If model improvement using your data is something you want, it is negotiated deliberately rather than assumed in a terms document.