Build a crypto research workflow you can review

Start your next crypto analysis with a research brief. Write the question, the evidence you intend to inspect and the conditions under which you will leave the question unanswered. This article presents our proposed editorial workflow for organising that work. Its checklists, examples and review rules are recommendations, rather than claims about investment performance.

The suggested output is a small research packet: a question sheet, a data record, an assumption register, a test report and a decision entry. Beginners can complete it with one instrument and one metric. Readers testing alerts can add configuration records. Readers supervising automation can add an event log. Choose the smallest exercise that you can document from beginning to end, without making a trading decision part of the assignment.

Write the research brief before choosing settings

Our proposed first step is to replace a broad market opinion with an answerable question. For example: “Within a specified historical sample, what price changes followed a defined condition over the next six hours?” Treat this as a description of the study you want to conduct. Do not append an instruction to buy or sell.

Complete the brief with an instrument identifier, market type, data interval, sample dates and observation horizon. In our fictional classroom exercise, use instrument Y on a spot market, hourly observations and a six-hour follow-up window. These are invented teaching parameters. Choose sample dates for your own exercise and record them before inspecting the results.

We suggest specifying the required output as well: an event count, a table of changes after each event, a summary chart and a list of exclusions. Define what an incomplete answer looks like. For example, mark the study “pending clarification” if you cannot determine which timestamp the metric uses. Make that status part of the plan, rather than improvising a conclusion after the test.

Give every dataset its own record

Our proposed data record begins with the metric name and its provider's definition. Add the unit, original provider, retrieval location, instrument, market and retrieval date. If you cannot locate a definition, write down the unresolved question. Avoid substituting a personal interpretation for an undocumented definition.

Next, record time conventions. Include the time zone, sampling interval, meaning of each timestamp and intended analysis horizon. Give publication delay a separate field. Enter the documented typical delay when you have evidence for it; otherwise write “not established”. In our notebook convention, an hourly interval and a publication delay are separate entries, and neither field fills in the other.

For a first inspection, we propose marking missing records, repeated timestamps, unexplained unit changes and sections with uncertain provenance. Record whether your working material is a raw download, an export or a chart reading. Preserve the input you used and add a note for each transformation: the operation, its purpose and the filename of the output.

Finish with one of three proposed working statuses: “ready for this exercise”, “needs clarification” or “set aside”. These are our organisational labels, not a data-quality certification. Alongside the status, state the unresolved issue and the next action. A useful completed record can end with a question to the provider rather than approval to continue.

Keep assumptions separate from observations

We propose three notebook categories. An assumption records a choice made before inspection. An observation records something read from the study material, with a reference to that material. An interpretation records a tentative explanation or a question for another test. Date each entry and identify the version of the study it belongs to.

In our invented exercise, an assumption could be: “Evaluate the condition only at the close of each hourly observation.” A fictional observation could be: “The exercise file contains 24 qualifying events.” A proposed interpretation could be: “Test the same definition in a separate period.” The number 24 is a teaching example, not a reported finding about an asset or MaxData.

For each interpretation, we suggest writing at least one alternative to investigate. You might plan a comparison with periods without the condition, or inspect the same rule in another sample. Leave both explanations open until you have prepared the relevant study. Do not turn an alternative question into an asserted market cause.

Finally, define invalidation rules for the research packet. Our suggested rules include an unresolved metric definition, an unreproducible configuration or missing observations required by the condition. If one applies, return to preparation and list exactly which conclusions remain open. Treat revising the brief as a documented decision.

Specify the notification rule in plain language

MaxData's English alert documentation describes an Alert as a notification based on one condition and a Pro Alert as a combination of several conditions. It also describes a time window for satisfying those conditions, a sleep period after triggering and selection of data inputs such as open or close. These are descriptions in the cited documentation, rather than confirmation of a particular account's feature access. Pro Alerts documentation.

Before configuring an exercise, our proposed rule sheet asks for the metric, comparison operator, threshold, unit and evaluation time. For a combined rule, specify the permitted interval between its component conditions. Add your intended handling of missing readings, repeated triggers and expiration. Give the configuration a version number rather than identifying it only by a template name.

Write three test cases before observing notifications: all conditions satisfied, only one condition satisfied and an incomplete reading. For each, record the expected response. When you inspect the exercise, place the observed response beside that original expectation. If you change the specification, preserve the earlier version and state why you changed it.

Inspect historical results with a defined protocol

The English MaxData backtest guide describes checking how often an Alert or Pro Alert would have triggered historically. It describes average and median price-change lines before and after the alert, and testing either one condition or several conditions together. Backtests guide.

Our proposed report should start with the sample dates and event count, followed by the configuration version and exclusion rules. Record how you handled overlapping observation windows. Describe the result as historical, and place any proposed future expectation in a separate hypothesis field. In this convention, a historical summary does not automatically populate a forecast.

If you include a transaction simulation, we suggest documenting assumed fees, slippage, hypothetical position size and the liquidity criterion. For each input, identify the evidence used or mark it as an invented exercise assumption. If execution inputs have not been included, label the report as a price-observation study rather than a record of executed trades.

For reviewing possible fitting to the chosen history, our proposed protocol records every configuration attempted, including discarded variants. Reserve another period for checking a configuration fixed in advance. If you revise the parameters after inspecting that period, open a new study version. We present this as a documentation convention, without a promise of future results.

Include a limitations paragraph written specifically for the exercise. State what remains unverified: timing, source definition, sample coverage, execution assumptions or the handling of repeated events. End with the next question to investigate, rather than a declaration that the rule should be used for trading.

Record the decision before scheduling its review

Our suggested decision journal accepts research decisions as well as configuration decisions. “Request clarification”, “repeat the extraction” and “continue observing” are valid entries. For each, record an identifier, timestamp, research question, data version, assumptions, alternatives considered, rationale and review trigger.

A fictional entry might read: “R-021: keep the notification study in observation mode. The publication delay is undocumented. Next action: ask the provider what the timestamp represents. Review after receiving a usable definition.” This entry deliberately addresses the research task. Do not add an opinion about price direction unless that opinion is a separately specified hypothesis.

At review, append a new paragraph below the original entry. Our proposed questions are: Did you follow the recorded procedure? Can you reconstruct the dataset and settings? Which uncertainty has been resolved? Which question requires a new experiment? Keep the initial rationale available and date every amendment.

For automation supervision, we propose an additional event record containing the expected trigger, observed trigger time, notification receipt time, intended action and action confirmation. Define pause conditions for the exercise, such as a configuration mismatch, unexplained repetition or an action you cannot account for. These are proposed supervision rules, not evidence that automation will avoid losses.

Finish with an actionable handover note

Before closing a session, our proposed checklist asks for one clear question, a completed data record, explicit uncertainties, a saved report and a review date or trigger. If something is missing, make it the next task. Leave a short handover note that another reader could use to locate the files and understand why the study stopped.

The MaxData Help Hub presents an assistant for questions about MaxData and the workspace. MaxData Help Hub. In our workflow, a support question should include the metric name, interval and exact uncertainty. Save the answer with the research packet, distinguishing the provider's explanation from your own commentary.

This article is educational. The invitation to create a MaxData account is a commercial element. For a first exercise, prepare an empty research packet, choose one question and complete the documentation without attaching a transaction to the outcome.