Ora
All documentation Overview

Get started

IntroductionQuickstartHow ora-fin1 decidesHow to build with OraUse-case map

Rule language

OverviewGrammarOperators and beliefsPrices and offsetsWindowsIndicatorsSignals and eventsPattern functionsFunction referenceRule libraryCommon mistakesError messagesEarnings and dividend facts

Questions & answers

Questionsyes_no (noul)choicescoreConfidenceThresholds and calibrationStateAsk by symbol

Patterns

Patterns

Actions & workflows

OverviewRules and templatesDestinationsWebhooks and signaturesWorkflows

API reference

POST /v1/systemoneGET /v1/models

Errors & limits

ErrorsRate limitsKnown limitations

Pricing

Pricing

Resources

FAQChangelogModels & versionsCode in 8 languages

Docs / Get started

Get started

How to build with Ora

Ora is a component, not an agent. Your code owns the workflow; Ora answers narrow, typed questions fast, and your code decides.

Principles
  • Keep control flow in your code. Ora answers; it does not decide what to do next.
  • One idea per question. Combine answers in code or in an action rule.
  • Rules for facts, forecasts for outcomes. Never ask a model to guess what you can compute.
  • Batch independent questions in one request.
  • Set a line per question, and dry-run before anything is delivered.

1. Start from the decision

Write down what you will do differently depending on the answer: size down, add to a watchlist, block an order, page someone. If no answer would change what you do, do not ask the question.

2. Split it into questions

"Is this a good long?" is not one question. It is a trend fact, a momentum fact, a risk forecast and a direction forecast:

QuestionKindAsk as
In an uptrend?Fact"ask": "C > sma(C, 200)"
Pulled back?Fact"ask": "C < sma(C, 20)"
Higher in a week?Forecast"instructions": "Will the stock be higher in a week?"
A 5% drawdown first?Forecast"instructions": "Will it drop at least 5% at some point in the next month?"

3. Prefer a rule when the answer is computable

A rule is exact, explainable and the same every time for the same bars. English "now" questions are compiled to rules when the compiler recognises them; write the rule yourself when you need to be sure (Rule language).

4. Batch

All questions about one symbol go in one request: one round trip, one fill of the market data, one bill. A watchlist is one request per symbol, sent in parallel (Rank a watchlist by probability).

5. Decide with lines, in one place

Answers are numbers, so a decision is a comparison. Keep the lines in one place (an action's when, or one function in your code) so they can be reviewed and changed together:

def decide(a):
    trend, pull = a["trend"]["yes_no"], a["pullback"]["yes_no"]
    up, dd = a["up_week"]["yes_no"], a["drop5"]["yes_no"]
    if dd >= 0.7:
        return "stand_aside"            # risk first
    if trend >= 0.6 and pull >= 0.6 and up >= 0.55:
        return "buy_the_pullback"
    return "watch"

6. Route the unclear middle

Answers near 0.50 carry little information. Act automatically only outside a band and send the rest to a person (Gate actions on how clear the answer is).

7. Move it server-side when it works

Put the same lines in actions to have Ora post to Slack or call your webhook, then in a workflow to run it over a watchlist every day (Turning a rule into an alert or workflow).

8. Log what answered

Store version, the answers, any rule and context.as_of with each decision, so you can audit it and measure your lines against outcomes (Choosing thresholds and calibration).

Information, not investment advice. Beliefs and probabilities on this page are real responses for the session shown and change with every session.

Create an account Open the Playground Everything here also lives in the console, next to your keys and usage.