Replace an idea with an instruction you can check
‘Buy when the market looks strong’ leaves the asset, meaning of strong, amount and timing undefined. A reviewable instruction names the exchange account, Spot pair, observations, comparisons, order and limits. If a required field is blank, the instruction is unfinished; a template or AI draft should not silently choose it for you.
Keep three layers separate: the signal describes a market condition; the action describes an order; mandatory checks decide whether that action is currently permitted. A true signal is not proof of a submitted, accepted or filled order. The worksheet below is an original paper exercise, not an executable SharkRule configuration.
Copy this worksheet and fill every required field
| Field | Write down | Check before approval |
|---|---|---|
| Identity | Rule name, version, exchange account, exact Spot pair | Which account and asset can this affect? |
| Inputs | Source, field, units, interval, completed or forming candle | Do both observations refer to the intended period? |
| Condition A / B | Left value, comparison, right value, AND or OR grouping | Does equality count? Is this a state or a crossing? |
| Entry action | Buy or sell, amount and its currency/unit, order type, any price limit | Is the action fully specified rather than implied? |
| Mandatory checks | Valid fresh data, permissions, available balance, no unresolved prior order | Must all pass whichever signal branch is true? |
| Limits | Per-action commitment, costs, cumulative cap, maximum actions, repeat policy | Can another rule or open order already reserve the balance? |
| Optional exit | Disabled, or exact asset/quantity, trigger, order type and limits | Has this exit been separately reviewed and approved? |
| Lifecycle | Expiry, pause behavior, failure handling and retained records | What happens to already submitted orders? |
| Approval | Reviewed version, chosen mode and explicit start | Does the screen match this version of the worksheet? |
AND needs both conditions; OR needs at least one
For this hypothetical example, A means the close of a completed candle is strictly above 100 quote units per asset unit. B means the same candle’s volume is strictly above 200 asset units. These invented thresholds illustrate logic, not an asset choice or trading recommendation. A close of exactly 100 makes A false; volume of exactly 200 makes B false.
AND permits the signal only when A and B are both true. OR permits it when either or both are true. TradingView’s operator reference documents these Boolean meanings; it does not establish a connection to SharkRule. More true rows under OR do not prove better trades, and fewer under AND do not prove safer trades.
| Close | Volume | A | B | A AND B | A OR B |
|---|---|---|---|---|---|
| 101 | 250 | True | True | True | True |
| 101 | 180 | True | False | False | True |
| 99 | 250 | False | True | False | True |
| 99 | 180 | False | False | False | False |
Put mandatory checks outside the choice of signal
Write the decision as: all mandatory checks pass AND (A OR B). Do not write (mandatory checks AND A) OR B: the second expression would let B bypass those checks. For example, with exhausted spending room, A false and B true, the first decision blocks the action; the second incorrectly permits it. Parentheses make the intended grouping visible.
This worksheet requires valid, fresh values for both inputs before evaluating either signal. If volume is missing while the close is 101, record ‘not evaluated: missing volume’ and permit no action. Do not replace missing volume with zero or remove B. This is an explicit data policy, not a universal property of OR: ordinary Boolean logic can resolve true OR another value without consulting that value.
Define freshness and the time interval in the actual rule. A current price and yesterday’s volume do not automatically describe the same observation. A value that is stale, malformed or from the wrong pair fails the data check even if its number would pass a threshold.
Worked spending check: two permissions, eight units left
Assume a paper rule allows at most two entry submissions in its run. Each reserves 20 quote units for the purchase plus 1 quote unit for costs, against a cumulative commitment cap of 50. All figures are hypothetical, not exchange fees, minimums or recommended amounts. The exercise counts permissions and reservations, not fills or profit.
Entry 1 reserves 20 + 1 = 21. Entry 2 brings the total to 2 × 21 = 42, leaving 50 − 42 = 8. A third would require 63, which exceeds the cap by 13, and would also exceed the two-entry limit. A true OR branch does not create an extra budget.
The actual order still needs an amount unit and order type. Spending 20 quote units is different from buying 20 units of the asset. Coinbase’s order reference separates the product, side and order configuration, including base and quote size fields. Review the applicable order requirements; this example does not assert that a particular pair accepts a 20-unit order.
Keep open-order commitments and uncertain outcomes in the record. Do not release a reservation merely because a request timed out. Reconcile actual fills and costs before updating the remaining allowance; stopping a rule is not evidence that an exchange has cancelled its existing orders.
Write an exit as a separate instruction
‘Sell later’ is not a complete exit. If an automated exit is wanted, specify the holding it can affect, quantity, exact trigger and reference value, order type, any price constraint and applicable limits. Review what happens after a partial entry or partial exit and what prevents repeated selling of the same quantity.
If no exit has been chosen, record ‘automatic exit disabled’. That does not close a position or eliminate loss. Do not add a sell instruction to an existing purchase-only rule without a fresh review and approval of that change. An AI-generated exit is still a draft until its exact parameters are accepted.
Test decisions before testing performance
Common mistakes include mixing candle intervals, confusing ‘above’ with ‘crosses above’, omitting amount units, interpreting a preview as a fill and treating a new draft as permission to alter a running rule. A worksheet exposes those ambiguities; it cannot establish profitability.
- Read the rule aloud with the exact account, pair, units and interval. Replace vague words such as ‘high’, ‘soon’ and ‘small’ with your chosen definitions; leave it unapproved if they are unknown.
- Work through all four AND/OR rows. Add equality at 100 and 200, a missing input, an old observation and a different pair. Write the expected reason for every permitted or blocked action.
- Repeat a true observation and replay the same event identifier. Specify whether a later observation may act again and how duplicate delivery is recognized. Consult the separate cooldown guide for timing policies.
- Test an exhausted cap, an outstanding order and an unknown submission outcome. Make sure B cannot bypass these checks.
- Review the optional exit independently, including partial fills and insufficient holdings. Save the reviewed version and compare it with the controls actually available before explicitly starting a supported simulation.
Use the worksheet to review a draft, not to infer a feature
From the SharkRule homepage linked in Sources, review the current rule-drafting and virtual-funds workflow. The public product describes drafting a price-drop or scheduled purchase, asking for missing settings, and reviewing rules and virtual budget before an explicit simulation start. Compare the resulting draft with your worksheet and use only the conditions actually offered; arbitrary AND/OR combinations are not established by this guide.
A paper check or simulation cannot guarantee live fills or returns. Fees, slippage, non-fills, outages and losses remain possible. Availability depends on the current dashboard, account and location; a documentation example is not approval for live trading. SharkRule is independent software, not affiliated with or endorsed by the cited exchanges or tools. This is education about rule mechanics, not financial or investment advice.
Frequently asked questions
Does no-code mean I can skip specifying the rule?
No. It changes how you enter instructions, not the decisions the software needs. The account, pair, condition, amount, order, limits and optional exit must still be unambiguous.
Can OR bypass a budget limit?
It must not in this worksheet. Both signal alternatives sit inside a separate requirement that every mandatory check passes. Write the parentheses explicitly and test a true signal with an exhausted budget.
Should a missing indicator count as false?
Not under this worksheet’s policy. Both inputs must be valid and fresh before evaluation. Missing information produces no permission and a recorded reason, even if the other OR branch is true.
Can I paste the example into SharkRule?
Treat it as a review aid, not an import format or a supported strategy. The available builder determines which inputs and combinations can be represented. Keep unsupported instructions unapproved rather than approximating them silently.
Official documentation and references
Prepared with AI assistance from the linked official documentation. Examples are hypothetical; no live account tests or return comparisons were performed.
- TradingView: logical operators and expression grouping
https://www.tradingview.com/pine-script-docs/language/operators/ - Coinbase Advanced Trade: order fields and configuration
https://docs.cdp.coinbase.com/api-reference/advanced-trade-api/rest-api/orders/create-order - SharkRule: current rule drafting and virtual-funds review
https://sharkrule.com/