Turning Strategies On and Off

In the last chapter, we learned what automatic means in TraderLobby. Now we will examine the controls that let you choose which strategies can work. The goal is more precise than making a button turn green. You should be able to identify a strategy, prepare its context and limits, enable it deliberately, and verify what changed. You should also know how to stop new activity without accidentally treating an open holding as if it had disappeared.

Start with the Strategies section in the navigation. This is where you can explore offerings and open their details. A marketplace card introduces a strategy. It is not proof that you have access to it, that it is configured in your account, or that its decision engine is on. Those are separate states. Keep that distinction in mind even when a familiar name appears in several parts of the app.

Use the search and available collections to find the strategy in the demonstration. Read its name and creator or source before opening it. If the list looks smaller than expected, check your search, filters, and selected collection. A narrow view can hide an offering without removing it from the catalog. A loading error is different from a successful search that has no matches.

Your Trading workspace provides another useful view: the strategies selected for that context. The strategy cards there summarize the mode, enabled state, and available activity or capacity information. Open a card's settings to inspect its controls. The marketplace helps you discover and understand an offering; the Trading view helps you manage the strategies selected for use. Neither view should be interpreted without checking Paper or Live.

Availability can depend on access, account requirements, or the offering's current state. Read the reason shown when an action is unavailable. Do not purchase access or change the account mode simply to make a lesson button usable. Our demonstration will use an eligible example strategy in an isolated Paper account. You can follow the explanation without enabling anything in your own account.

The same strategy may appear in a marketplace list, a subscription list, and a Trading card for different reasons. Think of those as different questions being answered. What exists? What access do I have? What have I selected for this mode? A name appearing in one list does not answer the other two questions. A name disappearing from a filtered list does not establish that its automation has stopped.

For your first checkpoint, find the example strategy in the marketplace and locate where you would manage its selected-mode settings. Say which view you are using and what it proves. If you cannot yet identify the mode or access state, pause the exercise at that point. A clear starting context makes every later change easier to understand and verify.

Before enabling a strategy, read its detail page as an explanation of a job you may authorize. Begin with the name, creator or source, and the public description. What is it intended to do? What limits or conditions are described? You do not need access to its private recipe to understand its stated purpose. You do need enough information to explain what you are choosing in plain language.

Read the available Paper and Live information separately. Access in one context does not establish access in the other. A control can show an access requirement, Add to a mode, or a decision-engine state. These labels describe different stages. Do not skip over the label because the strategy name looks familiar or because you have used another strategy from the same creator.

Next, inspect the evidence that accompanies the offering. Read the source, time period, sample size, and any assumptions or limitations provided. Historical research, recorded Paper activity, and Live results are different kinds of evidence. They should not be merged into one imagined performance record. A large percentage with little context is a reason to look more closely, not a substitute for that context.

For example, a win rate describes the share of counted trades that met the displayed definition of a win. It does not tell you the size of each gain or loss. A strategy can have many small wins and fewer large losses. A historical return also belongs to the period and setup reported. Neither number tells you what your next trade will earn, or whether the strategy fits the resources you intend to allow it to use.

Version information matters because an offering can change. Read the current version and any available release notes or update notice. Keep historical evidence attached to the version it describes. Do not assume that a pending update has already been accepted or that every older result was produced by the current behavior. When the app asks you to review a change, read that change before treating it as routine housekeeping.

Reviews and linked discussions can supply useful questions. Look for specific observations about the user's experience, dates, and context. Popularity and positive feedback do not replace checking access, settings, and evidence. You can inspect these sections without posting a message or submitting a review. The purpose here is to understand the offering, not to endorse it.

Your checkpoint is a short explanation with four parts: this is the strategy, this is its stated purpose, this is the evidence I can inspect, and these are the limitations or unanswered questions. If an important answer is missing, leave it missing rather than guessing. The next step is to separate obtaining access from actually giving the strategy permission to make new decisions in your selected mode.

Access means that the app allows you to use an offering under the applicable requirements. Activation is a separate choice about whether its decision engine is enabled. In between, there can also be a configuration step that selects the strategy for a mode. Understanding these stages helps you avoid two mistakes: assuming a subscription has started trading, and assuming that adding a card to a workspace has already turned its engine on.

In the current strategy detail view, an eligible strategy that has not been configured for Paper can show Add to Paper. In our isolated demonstration, selecting that action adds it to the Paper setup with the decision engine off. This gives you a chance to review its settings. Read the returned label. Adding and enabling are separate steps here; do not assume that the first click authorizes new entries.

Once the strategy is configured, the mode control can display Decision engine Off or Decision engine On. The Trading card and its settings also show enabled or disabled state. These labels concern that strategy in that mode. They do not establish the state of another strategy, another mode, or every exchange connection. Always keep the mode label in the same mental sentence as the engine state.

Some offerings require a subscription or another form of access. Read the current price, billing interval, and terms before any real purchase. A checkout may take you through a separate payment flow. Starting that flow is not proof that it finished successfully. When you return, verify the access status actually shown. Our lesson uses existing example access and does not require you to buy a subscription.

Access can also be affected by the offering's availability, an account restriction, or a version or lifecycle notice. If the control gives a reason instead of an available action, read that reason first. An access restriction and a connection problem call for different investigations. Clicking repeatedly or increasing a budget does not resolve every kind of unavailable state.

Imagine that you have an active subscription but the Paper decision engine is off. There is no contradiction. You have access, but you have not currently authorized that engine to make new entry decisions in Paper. Now imagine that Paper is enabled while Live remains unavailable. Those labels can also be consistent because the two modes have separate requirements and states.

For your checkpoint, describe the path as access, add or configure, review settings, then enable and verify. Do not compress it into subscribe and trade. In the next page, we will inspect the mode, account, and resource settings before changing the enabled state. That ordering gives you a chance to understand the limits before the strategy is allowed to use them.

Open the selected strategy's settings in the Trading workspace. Begin at the top of the dialog and read the strategy name and Paper or Live label. Before reviewing any number, confirm that this is the context you intend to change. For Live use, the relevant exchange connection and its capital limits matter too. A correct amount in the wrong account is still the wrong instruction.

The Decision engine control allows this strategy to open new positions. Leave it off while we inspect the example settings. Position slots describe the maximum concurrent holdings permitted by that setting. Concurrent means open at the same time. Slots are capacity limits, not instructions to buy that many coins immediately and not a promise that each holding will be in a different market.

Capital allocation describes how an entry amount is chosen. The available choices include Strategy default, Fixed amount per entry, and a percentage of PCR per entry. PCR means Potential Cash Realize, a figure discussed in the cash lesson. Read the selected choice and its explanation. Changing the method changes how the requested entry size is determined; it does not remove strategy risk limits or exchange requirements.

A fixed amount makes the requested amount easier to describe. For a fictional Paper example, two slots and a fifty-dollar target per entry could allow two entry targets of fifty dollars each. That is an illustration of settings, not a recommended allocation. It also does not prove that one hundred dollars is available, reserved, or certain to be invested. Other commitments and applicable checks still matter.

A percentage of PCR uses a changing basis. If the relevant basis changes, the resulting target can change too. Do not confuse a percentage of that figure with a percentage of cash that is immediately free to spend. Strategy default also depends on its defined allocation behavior. Read the current explanation rather than assuming all methods produce the same entry size.

Where shown, a minimum entry and Use remaining eligible cash add further conditions. Using remaining cash is not permission to ignore an exchange minimum. The app's explanation says remaining cash may be used when the target cannot be met only if the exchange minimum can still be satisfied. A small remainder may therefore be insufficient for an entry. An enabled strategy can legitimately wait when the required capacity is unavailable.

Review the complete settings before choosing Save strategy settings. The settings dialog keeps your edits together until you save them. Read the returned state afterward, and reopen the settings if necessary to confirm the stored values. A changed field before saving is not proof of a saved configuration. If the app reports invalid input or insufficient capacity, address the stated problem instead of raising several limits at once.

Your checkpoint is to explain the example without using the word budget loosely. State the mode and account context, the slot limit, the allocation method, and any minimum or remainder behavior selected. Then identify the resources already committed elsewhere. If two strategies depend on the same account funds, those funds do not become two separate wallets just because the settings appear on two different cards.

We are ready for a controlled Paper demonstration. The example strategy is accessible, configured, and still off. Its identity, mode, and resource settings have been reviewed. You can watch this sequence without changing your own account. The learning goal is to connect an intentional change with a verified state, not to produce a trade during the lesson.

In the example settings dialog, turn on the Decision engine control. Read the helper text: it allows this strategy to open new positions. Before saving, check the mode and the other settings once more. Saving the dialog submits the settings together, including the enabled state. Do not use a real account as a practice screen just because Paper appears somewhere else in the application.

Select Save strategy settings once and wait for the response. Then inspect the strategy's returned status. The Trading card should reflect the current enabled state when the save succeeds. You can reopen the settings to confirm the stored choice and values. If the request fails or the result is uncertain, investigate that message instead of treating the state you selected before saving as the final answer.

The configured mode control in the strategy detail view offers another route to changing its decision-engine state. Unlike editing a dialog and then saving, selecting that mode control sends its change directly. Read the current label before using it, and verify the refreshed state afterward. Do not click a second time simply because you expected a different animation; a second successful toggle could reverse the first change.

Now distinguish enabled from actively buying. The strategy may still be waiting for its conditions. Funds may already be committed, an account-level restriction may apply, or a connection may be unavailable. Enabling authorizes the decision engine within the relevant boundaries. It does not promise a new position, a particular entry price, or immediate activity.

If a recorded action later appears, identify its strategy, account, mode, market, and time. Check Portfolio and Transactions rather than relying on a brief notification. A candidate is not a fill, and a request is not proof of a completed purchase. The previous chapter's sequence still applies: observe, evaluate, check, request, and verify.

Before ending this page's demonstration, note the verified state and what remains unchanged. The example Paper strategy is enabled, but that does not describe Live or another strategy. In the next page, we will turn it off deliberately and check the consequences. Keeping the start and stop parts of the exercise together is a practical way to avoid leaving a demonstration running without a clear reason.

Turning something off starts with deciding what you intend to stop. Do you want one strategy to stop making new entry decisions? Do you need to inspect a broader trading pause? Are you trying to close a particular holding? Those are different intentions, and the controls are not interchangeable. State your intention first so you can judge whether the selected action actually accomplished it.

For the isolated Paper demonstration, our intention is to disable the example strategy's decision engine. Open its settings, confirm its name and Paper context, turn the engine off, and save. Inspect the returned Disabled or Decision engine Off state. If you use the configured mode control directly instead, verify the refreshed result after that request. In both cases, the evidence comes after the change.

Next, inspect Portfolio. Turning the engine off is not a sale instruction. Existing holdings may remain, and their values can continue changing. Check the owner, account, and mode for any relevant position. A remaining holding is not proof that the off control failed, because stopping new entry decisions and closing an existing position are different jobs.

Position monitoring needs a separate check. The Decision engine helper describes permission to open new positions; it is not a universal description of every exit watcher or protective process. Do not assume either that all exits stopped or that every exit will continue unaffected. Inspect the relevant position, alerts, and current control state before relying on ongoing monitoring. A changed strategy label cannot replace that review.

The broader Trading pause, when available to your role, has its own scope. Read the account and mode involved and the status returned by the control. A pause can affect automated exits as well as entries. Do not treat it as a way to preserve every protective action while stopping only purchases. A protective interruption or reset message also deserves investigation before you resume anything.

A request already sent needs its own outcome check. A later disable or pause does not establish that an exchange canceled an earlier order. If you are uncertain about a submitted action, inspect the appropriate records and account context before repeating it. Closing a browser tab, moving to another section, or viewing Paper does not settle that question. Enabled Live work can continue outside the workspace you are looking at.

For your checkpoint, report two separate findings: the engine state you verified and the position state you verified. If an outcome is unresolved, say so and identify the next check. The example exercise is complete only when you can describe the actual stopping point. An off label is useful evidence about a control; it is not a receipt proving that every related holding or request has ended.

The word remove can hide several different intentions. In this app, removing a strategy from a mode is separate from canceling its paid subscription. It is also separate from closing the positions associated with it. Before confirming any removal, read the full dialog and name the outcome you want. A short button label should never be your only explanation of a consequential change.

In a selected strategy's settings, Remove from Paper or Remove from Live opens a mode-specific confirmation. The current dialog explains that this removes the strategy from the trading table and stops it from making new decisions in that mode. Read the strategy name and mode in the heading. Removing it from Paper does not establish that a separate Live setup has been removed.

If the strategy has a subscription, the dialog identifies that the subscription is unchanged and provides a Manage subscription route. Keep strategy returns without confirming the removal. The remove action is not a sell request and is not the billing cancellation workflow. After any actual removal, inspect the relevant positions and their ownership separately; a missing Trading card does not establish that its holdings were sold.

Billing has a different path. In the subscription view, Cancel renewal is the control to inspect when your intention concerns future subscription billing. The current cancellation flow checks for open positions. Where holdings require a choice, it shows their markets, modes, and estimated values. Read the current period and returned subscription status as well. Canceling renewal is not a promise of an immediate refund or a reversal of earlier charges.

The position dialog explains that new trades from the strategy will stop immediately while paid access remains available until the end of the billing period. Keep as APP slash manual retains the holdings under manual ownership. That choice does not sell them. It changes who is responsible for managing them through the available app controls. Afterward, verify their ownership and account context in Portfolio rather than assuming the former strategy still manages them in the same way.

For eligible Paper holdings, the dialog offers Sell Paper holdings and cancel. This is a separate choice from keeping them. It concerns simulated Paper holdings and still requires a successful result. If prices are unavailable or the operation fails, do not describe the positions as closed. Read the message and inspect the recorded outcome. The lesson will demonstrate these consequences with fictional data, not by liquidating your account.

When Live holdings are present, the current dialog disables that combined liquidation choice. It explains that Live sales require confirmed exchange orders. The available retention path keeps the holdings as APP slash manual so they can be handled through the appropriate Portfolio actions later. Never interpret subscription cancellation as proof that real holdings were sold. Mixed Paper and Live holdings also require careful reading of the options actually enabled.

If no holdings require a decision, the cancellation route can be shorter. Do not assume every unsubscribe action is a harmless preview that you can explore by clicking. Read the control and subscription context before using it. For this lesson, inspect a clearly labeled example dialog or watch the demonstration. No real renewal cancellation is needed to understand the workflow.

Your checkpoint is to explain three different outcomes: removed from a mode, renewal canceled, and positions kept or closed. Identify where each outcome would be verified. If you cannot explain the position choice or billing consequence, use Go back and investigate. The useful result is a deliberate decision with evidence, not simply the disappearance of a card or dialog.

Managing several strategies means repeating the same careful questions without losing track of context. More cards do not create more account funds. More enabled engines do not automatically provide more useful activity. Begin by identifying which strategies are selected, which are enabled, and where they may act. Then consider their combined demands on the resources available to that account.

Use a simple fictional Paper example. Strategy A has two slots and a fifty-dollar target per entry. Strategy B also has two slots and the same target. Together, those settings could describe four fifty-dollar entry targets before other constraints. If the shared account has only one hundred dollars available, the two cards have not created two hundred dollars of spending power. The actual permitted actions still depend on funds and applicable checks.

Open positions also belong in that review. Read their owner or strategy and account context. Two engines may be interested in the same market, and similar symbols can appear on different holdings. Do not assume that adding another strategy automatically diversifies the account or eliminates overlapping exposure. The point of this page is to understand the combined setup, not to recommend a number of strategies or a particular allocation.

Now rehearse a shutdown drill in the isolated example account. First write down the intended endpoint: stop new Paper entry decisions for the two example strategies, inspect remaining positions, and leave any unresolved result clearly identified. This drill does not require selling holdings or canceling subscriptions. If those were also your intentions, they would need separate decisions and separate verification.

Disable each example decision engine in the correct Paper context and verify the returned state for each one. Do not stop after changing the first card. Review the list again and confirm that the intended strategies are off. If another mode or account is relevant, inspect it separately; do not assume a Paper change answered a Live question. You can demonstrate this sequence without changing the viewer's real settings.

Next, inspect the example holdings, alerts, and relevant transaction records. Record what remains open and whether any submitted action has an unresolved outcome. If a holding is retained under manual ownership, identify that responsibility explicitly. If you later choose a broader pause, inspect its scope and effect on monitoring rather than treating it as one universal switch that safely completes every part of shutdown.

Finish with a short handoff note. State the context, the strategies checked, their verified engine states, any open holdings, and any unresolved requests or warnings. Include the time of the check. Leave credentials and unnecessary account details out of the note. This record helps you or another authorized person understand the actual stopping point without guessing from the color of a button.

You have completed the chapter when you can explain how to add, configure, enable, disable, and remove a strategy without mixing those actions with subscription billing or position liquidation. The important skill is not clicking quickly. It is knowing what each control changes and checking the result. Next, we will follow the activity trail in Transactions so you can connect those requests and outcomes to the records the app keeps.