Built to be audited before it is trusted.
This page is written for people who evaluate systems professionally. What the engine does, what governs it, what it refuses to do, what protects a position when something goes wrong, and where the engineering evidence is shown. No returns, no case studies, no adjectives you cannot check.
In short. ORO SAGE is an autonomous equity engine for NSE and BSE listed stocks. Seven roles carry and police every decision, orders leave only through one controlled route the broker has verified in advance, and every decision is recorded with its reason attached in a record that cannot be edited afterwards. It has traded the founder's own capital since August 2026. Not one live order was sent in the system's entire build history before that, because the whole machine was proved on paper first.
Two boundaries stated up front, because they decide whether the rest of this page is worth your time. Custody never moves. The engine places orders into a broker account that belongs to you or your client, through the broker's API. It has no withdrawal path and never holds capital. Autonomous execution for third-party money is gated. ORO SAGE is applying for registration under the applicable SEBI framework. Paid services open only once registration and broker algo-empanelment are in place. Until then this page collects expressions of interest and nothing here is investment advice.
Seven roles, each one a service with a single responsibility.
Four roles carry a trade forward. Three sit across the top and audit, record and govern. The separation is the design: no role grades its own work, and each hands the next a record of what it decided and why.
Analyst
Scores every candidate against a fixed pattern set and returns a defensible conviction number. Nothing downstream runs without it.
pipelineScreener
Sorts scored names into strategy books and separates what is tradeable today from what is only worth watching.
pipelineOptimizer
Chooses the action on every position (buy, sell, hold, trail, or swap a weaker holding for a stronger one) and sizes it inside the mandate's limits rather than by enthusiasm.
pipelineExecution
Places the order, sets the protective stop and target at the broker so they live at the exchange, moves the stop in your favour as a trade works, and owns the position book down to the paisa.
pipelineGatekeeper
The independent auditor. Verifies that the data is fresh, hunts for silent failure in the other roles, and can halt the system.
cross-cuttingReporter
Writes the append-only activity record. No judgment, no summarising, no tidying up afterwards.
cross-cuttingOracle
Governance. Reviews the week against stated goals, tracks whether conviction scores were honest, and holds the guardrails the other six run inside.
cross-cuttingWhat the system reads, and what it does when a feed goes missing.
A claim is only as good as the data under it, so every value the engine acts on carries where it came from and how fresh it is. A stale or fallback value is never allowed to present itself as live.
Sources and coverage
Degradation policy
One way out, verified by the broker in advance.
Under the SEBI algorithmic trading framework, orders placed through a broker's API are expected to arrive by one fixed route registered with the broker beforehand, with every algo identifiable. ORO SAGE was built that way from the first line, and no third party sits between a decision and your broker account.
Scroll sideways to see the whole diagram.
The route is proved rather than assumed, and the proof is repeatable in front of you. What that route is made of, and how it is tested, belongs in a working session rather than on a public page, so it is part of the walkthrough. The framework itself is explained in the SEBI algo rules, explained.
Append-only, reason attached, and it refuses to write when the numbers disagree.
Most systems log outcomes. The useful thing to log is the reason, at the moment the decision was made, before anyone knows how it turned out. That is the difference between a record you can audit and a record you can only admire.
Entries are added, never rewritten. The record cannot be tidied up after the fact to look smarter than it was. A losing trade appears in the same plain form as a winning one, and a candidate the safeguards rejected is written down alongside the ones that passed.
Every value carries its provenance. A price is not a price. It is a price from a named source at a known time, with its freshness attached, so a reviewer can reconstruct what the system could actually see when it acted.
The books are reconciled against the broker's own. If the broker's record and ours disagree, the system records no result and raises instead. The reasoning is deliberate: a late entry shows up the moment anyone reconciles, while a wrong entry spreads through profit and statistics wearing the same shape as a correct one. Visibly behind beats invisibly wrong.
The audit trail travels with the decision. Each record is readable by a reviewer without asking us for context, which is the only version of an audit trail that survives an actual review.
Shown in the walkthrough
The test suite is the claim we are most willing to be examined on.
Every figure below is read from build state and dated. There are no performance figures anywhere on this site, and there will not be until the live record is long enough to mean something.
What a test count is actually for
On its own it is a vanity figure, so here is what it buys you. Every safeguard described on this page has tests that prove it fires, and those tests are re-run before anything reaches the live account. The dangerous failure in automated trading is not the crash. It is the safety system that has quietly stopped working while continuing to report all clear, and the suite exists so that a machine notices that condition rather than a client.
The suite is harsher on itself than a green run suggests, and we are glad to be examined on that. How it is built, what it deliberately tries to break, and where it has caught us out are shown live in the walkthrough. That is the part that took years, and it is the part we do not publish.
Evidence, and its limits
What breaks, and what the system does when it does.
Every class below has a defined response that is tested rather than assumed. The pattern behind all of them is the same: positions keep their protection at the broker, and the system pauses rather than guesses.
Empty or missing universe
New buying halts. Open positions are still managed, the check against the broker's records still runs, and the record states plainly that the universe was empty.
Stale or degraded prices
Tagged degraded, or the run stops. A fallback value is never allowed to masquerade as live. The freshness breaker trips on its own numeric trigger.
A stop or target fires unattended
Protection sits at the broker, so it fires whether or not the engine is watching. The sale is then booked from the broker's own record at the price that actually filled, never from an estimate.
Records disagree
If the broker's books and ours do not match, the system writes nothing and raises. No estimate, no reasonable guess, no partially updated position.
Order rejected
A rejected order is retried a small number of times, and then that name is set aside for 24 hours. A run of rejections trips the rejection-cascade breaker.
Orders cannot go out
The engine can still see everything and simply stops placing new orders. Stops and targets stay live at the exchange throughout, so an outage costs opportunity rather than protection.
The system goes down mid-session
It comes back paused and stays paused until its own record and the broker's agree. Open positions keep their protection while it is away. It does not resume on optimism.
Broker session fails
Its own named safeguard. A failed broker authentication stops the run rather than retrying blind against a broker that is no longer listening.
The six named breakers
Each one has a numeric trigger set in advance, because a crisis is exactly when discretion is worth least.
- Fast drawdown. Down 7 percent over 10 trading days halts new buying for three days.
- Sustained drawdown. Down 12 percent over 30 trading days moves the book to a defensive posture for thirty days.
- Consecutive losses. A run of losing trades trips its own brake.
- Data freshness. Stale or missing market data stops new buying.
- Broker authentication. A failed broker session stops the run.
- Rejection cascade. A run of rejected orders stops the run.
Above all of them sits the kill switch. One command halts the system in 60 seconds or less, from wherever you are. It cannot fail silently, and a halt stays a halt until somebody deliberately clears it, which means a halt called at midnight is still a halt at the opening bell. Full detail on the safety page.
A managed engine inside your structure, not around it.
ORO SAGE runs as a managed service. The engine runs on our infrastructure and places orders into a broker account that belongs to you or your client, through the broker's API. Your mandate, your compliance wrapper, your name on the service. Guardrails are configuration rather than code: position and sector ceilings, cash-reserve policy by regime state, universe restrictions, breaker thresholds and mandate limits are set per desk.
Autonomous execution for third-party capital opens after SEBI registration and broker algo-empanelment. Before then, the engine can be evaluated, its record inspected, and a mandate scoped.
- Custody never moves. Capital stays in the client's own broker account and the engine has no withdrawal path.
- Every decision arrives with its audit trail attached, in a form a reviewer can read without asking us for context.
- A paper-parallel proving period runs before any client capital is committed. The founder's own book went through the same sequence first.
- The kill switch is yours to hold. Halting is not a support ticket.
- Commercial terms for the published retail plans are on the plans page. Desk engagements are scoped in the walkthrough.
What a pilot conversation actually covers.
One working session, screen shared, no slides. The purpose is to let you form a view on the engineering rather than on the marketing.
The mandate
Instruments, universe restrictions, position and sector ceilings, and what cash reserve you want held in each regime state. These become configuration, not a change request.
The evidence
The test suite run live, the full record schema field by field, and a real decision opened on screen rather than described in a deck. Bring the questions you would ask a vendor you distrust.
The integration
Which broker, whose account, who holds the kill switch, and what your operations team sees on a normal day.
The failure drill
We walk the failure classes above and show what the system does in each one, performed rather than described. Including the two that caught us out.
The proving period
What a paper-parallel run would look like on your mandate, what gets reported, at what cadence, and what would have to be true before capital moves.
The boundaries
What is live today, what is gated on registration and empanelment, and what does not exist yet. We would rather lose a conversation at this step than at the one after it.
The live record began in August 2026 on the founder's own capital and is not yet long enough to mean anything. When it is, it will be published from the record itself with the drawdowns shown alongside the gains, and prepared in line with the applicable verification requirements. Until then, the honest answer to "what are your returns" is that we are not going to show you a number we would not trust ourselves.
What remains to be evaluated is the engineering, and there is a great deal of it. It sits one layer below this page deliberately. The walkthrough is where the suite is run, the record is opened, and the failure drill is performed, which is the version an evaluator can actually interrogate and the version that stays ours. One working session tells you more than any datasheet, including this one.