Matka Chart Software: Tools for Analysis & Prediction

A Matka chart is a spreadsheet that somebody decided looks like a calendar. "Chart software" is the promise that it can be more than that: that the same grid of three-digit numbers, fed into the right tool, will tell you something you could not see by eye. Some of that promise is deliverable. Some of it is a change of font. And some of it is arithmetic that no chart in the world can deliver, because the data underneath is not the kind of data that carries a forecast.

What a Chart Tool Is Actually Being Asked to Do

"Analysis" is not one operation. It is a ladder of six, and each rung costs something different to build - which is exactly why marketing copy collapses them. Read the ladder from the bottom and you can place any feature claim, in any app, on the rung it genuinely occupies.

Everything we can inspect in this product lives on rungs 1-4, and the marketing sentence on the hub page is written as if it lived on rung 6. That gap is where the product category sits. Two of the rungs deserve to be taken apart in more detail, because they are where the money changes hands: rung 2, which people read as discovery, and rung 3, which people read as measurement.

Rung 2 is worth stating bluntly: no derived column on a Matka chart carries information the two pannas do not already carry. The ank is a function of the panna. The jodi is a function of two annas. The full result string is a concatenation. The "red" flag is a two-clause predicate. A tool that shows you these columns is a formatter, and a formatter that gets the rule from the wrong layer publishes a chart your bets will not match. This is not a hypothetical: in our own product the word is implemented twice, in two different layers, with two different definitions of the same thing - see the section below on recomputation.

Rung 3 is where a tool first has to be honest about something it cannot see: what it is dividing by. A count of draws is a number; a rate is that number over a denominator, and charts are full of cells that produced no draw. Our own product's grid geometry supplies a worked example, and it is worse than it looks.

Five Ways to Read One Chart, and Five Different Depths

Start with the most concrete fact about chart software, and our product will do to demonstrate it because we can read its source: the tool has a window, and the window decides what the tool can say. Here are all the depths at which the same declared results are served by the same codebase.

Twelve point zero five times. That is the ratio between the widest and narrowest fixed window in one product (1,097 dates over 91), and it is the fact a chart comparison most often fails to mention. Every statistic any of these pages could print inherits its window: a "most frequent digit" computed over the hourly chart's 91 days is a different quantity from one computed over the 3-year grid, and both are different again from what the JSON feed would give you. Neither is wrong. Both are uncomparable unless the depth is printed next to them, and in the product we can read, it is not printed anywhere. Note that each window is a >= test against a shifted date, so its own start day is inside the range - count the dates, not the subtraction, and every figure moves up by one.

Then there is the freshness layer, which quietly shrinks the window you think you are analysing. The chart pages are served with Cache-Control: public, max-age=60, stale-while-revalidate=120: a request can be answered with a copy up to 60 seconds old, and a further 120 seconds may be served stale while a refresh runs, so 180 seconds is the worst case for a page. The /charts hub uses max-age=30, stale-while-revalidate=60 - 90 seconds. Behind both, the server keeps its own chart cache for 10 minutes with a hard cap of 50 entries, and the cache key is the market identifier alone: the date range is passed into the method and does not appear in the key, so the cached payload belongs to whichever caller filled it first.

What Our Own Chart Pages Compute: A Census

Six templates make up the chart product: the /charts hub, the jodi grid, the pana grid, the Starline grid, the jackpot grid, and one error page. Seven route patterns serve them, plus four legacy .html aliases. Here is the total amount of page-specific JavaScript in them.

Two script blocks in the entire chart product, both the same feature, and neither of them computes anything: no count, no total, no sort, no average, no "N matches found". It is a highlighter. And it is a highlighter with a specific behaviour worth knowing before you trust it as a lookup tool - it matches with String.includes(), which is a substring test, not an equality test. Type 1 into the jodi chart's find box and it lights up 19 of the 100 possible jodi values: 01, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 21, 31, 41, 51, 61, 71, 81, 91. Type 22 and you get 1. The box does not find "the jodi 1", because there is no such record - it finds every cell whose two characters contain your two characters, which is a different question and the one nobody asks.

Meanwhile, the hub page that links to all of this says: "Historical charts show repeating sequences, red jodi occurrences, cut-number relationships, and weekly interval cycles, allowing analysts to formulate statistical estimations." That sentence is describing a capability the software does not have. Nothing in the six templates or the seven routes formulates an estimation. The estimation is the part you bring - at which point the honest name for the tool is not "analysis software", it is "a data view you are doing arithmetic on by hand".

One exception survives inspection, and it is small enough to quote in full. The only analytic predicate anywhere in the chart pipeline is one boolean function applied to one cell, once per week row, deciding whether to paint it red. Its rule is: the two digits are equal, or their difference is 5. That is it. It is a relabelling of a value already in the cell, and it is genuinely useful, because it lets a human see a structure - but it is not statistics, and it has a hard consequence for anyone who counts what they see, which is the subject of the section on denominators.

Every Cell Is a Recomputation, and One of Them Disagrees With Itself

Here are the rules our own chart applies to turn two stored pannas into the row you look at, taken from the method that builds each row rather than from the display layer.

Six columns, zero new facts. A chart tool that advertises "shows you the full panel" is advertising a formatter, and a formatter can be reproduced by anyone in a spreadsheet in an afternoon - which is worth saying out loud before you pay for one. The rules themselves are documented properly for players in the placeholder explainer, what a full pana record preserves and why a jodi like 07 must keep its leading zero; what belongs here is what a tool does with them.

The % 10 in the ank row is doing more work than it looks. Digit sums modulo ten are not uniform over the digit set - and every derived column inherits that structure - so a "frequent digits" table computed from the ank column is not measuring what a "frequent digits" table over a fair generator would look like. That is a real analysis question and it is one the probability layer handles properly in the win-probability analysis. This page's point is narrower: the tool is not adding information when it computes the ank, and it must not be trusted to be neutral when it then counts the results.

The Same Word Means Two Things in One Product

Here is the finding a chart tool can get wrong, in our own code, verbatim. The stored result object exposes a method that returns a "jodi" by concatenating the first two digits of that session's panna. It carries this documentation: @deprecated, "Jodi should NOT be computed from a single result", "This method incorrectly returns digit1+digit2 as string which is WRONG", "DO NOT USE - will be removed in future version". The chart does not use it. The chart builds the jodi the way the game means it - open ank plus close ank - at the service layer, exactly as the deprecated comment demands, and so does the admin payout calculator. But the getter still ships, still answers to the name, and still returns a two-character string that looks like the thing it is documented not to be.

Now put yourself in the position of a chart tool. It is given a feed of numbers and a data dictionary, or it is not given either and it reverse-engineers one. A field named jodi that contains 25 is indistinguishable by looking at it from a field named jodi that contains the open and close annas. Both are two digits. The difference is whether your published chart matches the number the book settles against - and the difference is invisible in the output. This is the entire reason "which chart software is accurate" cannot be answered by looking at charts, and why the only test that works is checking a derived column against the rule that pays. The jodi versus pana comparison walks through the two grid types a reader can actually see; this is what has to be true underneath them both.

Three Feeds, Three Different Answers to the Same Question

If you are going to build analysis on top of a chart product, you need a machine-readable feed. Ours offers three, and they are not interchangeable. We found this by trying to answer one simple question - what is the jodi on this date? - of each.

Three consequences, all verifiable, none of them visible in a screenshot.

One: two of the three feeds cannot give you a jodi at all. The public JSON emits two pannas and nothing else; the paginated feed emits six raw digits. Any tool consuming either must recompute the annas and join them - which is fine, provided it uses the same rule the settlement does. Only the HTML grid computes the headline column for you, and it does so correctly, at the layer the deprecated comment points to. So the three feeds split the work three different ways, and none of them tells a consumer which split it is using.

Two: missingness has two shapes in one field. The API branch tests whether the result object exists and writes *** if it does not. But the digit-sum getter it calls in the other branch returns null when any single digit is missing. So the same field can be a string of three asterisks, a JSON null, or a real panna - three states for one concept, with no documentation distinguishing them. A tool that tests == "***" silently treats the second state as a value.

Three: the timestamp is invented. Not rounded, not approximated - composed, in one expression, out of the result date and the literal text T00:00:00.000Z. That is midnight UTC, which is 05:30 in the market's own time zone, so it is not the declaration time of anything, and it is not the instant the row was saved (which the database does store, per session, in a declared_at column that no public feed exposes). A tool that reads that field as a time, in a browser set to a zone west of Greenwich, renders the day before the one the chart shows.

And one more, for the record: the paginated chart endpoint takes page and size parameters, validates that size is between 1 and 2,000, and then ignores both - the service hard-codes page zero with a 2,000-row fetch, with a comment explaining that this is deliberate, to avoid pagination problems on older client apps. Its javadoc says it "computes patti, digit, and jodi values". It computes none of them; it passes six raw digits through. When you evaluate chart software, the docstring is not the specification, and the specification is not the behaviour.

The Denominator Problem: What a Frequency Table Divides By

Aggregation is the first rung where a tool adds information, and the first place it can lie without saying anything false. The question is always the same: how many draws? And the answer on a Matka chart is smaller than the calendar suggests, for two structural reasons that our own grid makes measurable.

Reason one: the grid is bigger than the data. The weekly rows are built by taking each returned date and moving it back to the Monday of its week. Three years of days lands in Monday-anchored rows of seven cells. Counted at the publication window: 158 week rows, 1,106 grid cells, 1,097 dates - so nine cells in every chart can never hold anything at all, before a single result is declared or missed. And a row is created only for weeks that contain a returned day, so the emptiness is not uniform: it concentrates at the boundaries and around gaps.

Reason two: an empty cell and an unplayed day look identical. Every cell in a new week row is pre-filled with the same defaults: *** open panna, ** jodi, *** close panna, red = false, hasData = false. The template renders those glyphs for a day the market did not run, a day that ran but has not been declared, a day whose open has been declared and whose close has not - which gets its own partial token, the open ank plus a single asterisk - and a position inside a week row that falls outside the window. Four different real states, one picture. The mechanism is in the query, which admits a day if either session has digits - so a half-declared day is a row, a closed day is not a row, and the grid fills the difference back in with asterisks.

That last row is worth dwelling on, because it is the cleanest illustration of how a chart "discovers" a false pattern. The rule says a jodi is red when its digits are equal or five apart; enumerated over all 100 two-digit values that is exactly 20 of them - 00, 05, 11, 16, 22, 27, 33, 38, 44, 49, 50, 55, 61, 66, 72, 77, 83, 88, 94, 99 - a structural 20%, not an empirical one. Count that 20% over grid cells instead of declared days on a market with one off day a week and the chart will report 17%. Somebody will write that up as "red jodis have become less frequent". Nothing about the generator changed; the denominator did.

The related failure - missing dates inside a window rather than structurally outside it - has its own page, how missing dates can distort a historical frequency count, and the correction policy that keeps a record straight is in what a results site should show when an entry is corrected. Read those two against this one and the picture is consistent: a frequency table is only as honest as its denominator, and on a chart product the denominator is the one number that is never printed.

The Ranking Layer: What Noise Hands You for Free

Suppose the generator is perfectly fair. Suppose every digit has exactly one chance in ten, every day, forever. Suppose the data feed is complete - no missing days, no asterisks, no off days, no corrections. Suppose you use the longest window our product offers, 1,097 draws. Now rank the ten digits by how often they appeared.

Nothing has been discovered, and the table will still have a hot digit and a cold one. We simulated the fair case directly: 400,000 independent runs at each depth, ten equally likely outcomes, and the whole table re-run against a second, unrelated generator - the two agree to better than a fifth of a percentage point, so these are stable estimates rather than one lucky sample.

Read the 91-day line, because that is the window an hourly chart hands you, and that is where "hot number" strategies are born. Over 91 fair draws, the expected hottest digit sits at 15.4% of the draws and the expected coldest at 5.3% - the expected maximum of ten noisy counts is about three times the expected minimum at that depth, so a fair generator is expected to produce a lopsided-looking ranking at every single window length, and the lopsidedness you are looking at is the shape of noise, not the size of a signal. Nothing was found. The tool ranked noise and reported the ranking in the same visual language it would use for a signal.

Two more numbers from the same simulation decide most real arguments about chart software:

• 80.1% - the probability that the hottest digit over the last 91 draws of a series is a different digit from the hottest over the full 1,097. Two users, one product, one fair generator, two charts, two "hot numbers", and the majority of the time they disagree. The disagreement is not a data difference. It is the window.
• 99.9999% - the probability that at least one of the 50 market chart pages this product serves (25 seeded main markets x 2 grid types, over the 3-year window) shows a digit clearing two standard deviations. With ten digits tested per page and fifty pages, the "one in fifty" surprise is not lucky - it is inventory. If a chart tool lists a statistically notable digit, the interesting question is never what is the p-value, it is how many cells did you look at before you reported that one. That is the multiple-comparisons problem, and it is the subject of what a 90% accuracy claim must show.

Even the "seen it before" statistic that powers so many chart heuristics is arithmetic, not evidence. Over a 731-draw window, the expected number of distinct jodis seen is 99.9 of 100: a specific two-digit number has a 99.94% chance of already appearing, so "this jodi is due because it has not shown in a while" competes against a base rate that has almost certainly already been satisfied. At the 91-draw depth the same maths gives 59.9 distinct jodis seen, and the wider spaces barely start filling at all - a given ordered panna has appeared 8.7% of the time over 91 draws against 51.9% over 731. Patti classes, the 220 unordered families described in where the 220 patti count comes from, sit between the extremes: 212 of 220 seen over 731 draws (96.4%), 75 of 220 over 91 (33.9%). The lesson is not that recurrence is meaningless; it is that recurrence has a known value at every window depth, and a chart tool that reports a recurrence without reporting that baseline is reporting a number it has not read.

Same for gaps. The probability that a specific jodi fails to appear in a stretch of 250 draws is 8.11% - unremarkable - which means the expected number of jodis sitting at a 250-draw gap on any given day is 8.1 out of 100. At 300 draws it is still 4.90% per jodi, and at 365 draws 2.55%. A tool that flags "overdue" when a gap exceeds 250 is flagging eight cells a day on a product with 25 daily markets, and calling the result a pattern. When a number is called "due" handles the independence argument properly; this is the arithmetic version of the same mistake, made by software instead of by a bettor.

How Much Data a Real Bias Needs

Everything above assumes fairness, because fairness is the null the tool must beat. Now assume the opposite: the generator is biased, and the software's job is to notice. To make that concrete, take the ten digits, suppose one of them truly comes up at 10.5% instead of 10%, and ask how many draws you need before that difference clears two standard deviations.

Or invert the same formula to ask what each window can see. It is the most useful table on this page, because it converts "our chart tool spots patterns" into a falsifiable sentence:

So: any pattern-detection claim resting on the hourly chart's 91-day window is only capable of seeing a generator that is 63% broken. A ten-way game biased by 63% is not a subtle edge; it is a broken machine, visible in the results page without software. And the honest 3-sigma mark - the threshold you should actually use once you admit you looked at ten digits and picked the extreme one - is higher still: 19.4% at 91 draws and 12.7% at 1,097, while the expected hottest digit at 1,097 draws is 11.5%. In other words: the hottest digit you will ever be shown by a fair process does not reach the threshold at which you are entitled to call it hot. That is the sentence a chart analysis tool would have to print next to its own ranking. Ours does not print it, because ours has no ranking to print it under.

Note also what the arithmetic does not say. It is not a claim that Matka results are proven fair - no dataset here could prove that, which is the whole content of the table. It is a claim that the sample sizes on offer are too small to detect the biases that a prediction tool would need to be useful, and that any software whose revenue depends on finding a pattern will find one at exactly the depth noise guarantees. The rate ladder and what it costs to bet against your own conclusions is in the rate-list explainer and risk management.

The Aggregation Layer This Product Has, and the One It Does Not

Auditing a product for analysis features, the honest way, is a search for the aggregate query - and then for its callers. Here is the entire inventory of grouping operations in 306 server source files.

Nine grouping operations in the whole server. Eight of them aggregate money. The ninth is a result-frequency table with a name that reads like the engine of every "hot numbers" feature in the category - getResultFrequencyByGameAndDateRange, grouping declared results by their number and ordering by count - and it is called by nothing in the application or in any template. The feature was built and never connected. That is not a criticism of our engineers specifically; it is a demonstration of how easy the category is to satisfy on paper. A "result frequency" query exists in this codebase. A feature list generated from the repository could claim it. Nothing in the product would show it to you.

The census is a case-insensitive search over every .java file the server compiles from, matching on word roots (predict, forecast, frequenc, statistic, algorithm, probab) and on the standalone token for AI, counting both files and lines. So nothing hides behind an unusual capitalisation or a longer identifier - and here is the whole result, because it is exactly what a reviewer should be checking for:

Zero hits for forecast, trend, hot number, probability, machine learning or artificial intelligence, across 306 files. The word "algorithm" appears on six lines in three files, and all three are security or payments plumbing: a rate limiter's own comment, the JWT signing enum, a checked exception in the gateway client. If a chart tool's source were as inspectable as ours, this table is what a review would consist of - not stars.

"Prediction" Software: the Only Version Here Runs Backwards

The one endpoint in this product with "predict" in its URL is GET /api/admin/bets/predict-winners, restricted to the ADMIN role, with an admin page behind it. Its parameters are a date, a market, a session, and two openers: openPana and closePana - the result. The future is an input. The endpoint answers the question "given that the result turns out to be this, which placed bets win, how many winners are there, what is the total payout, and how much was staked". It derives each session's ank from the supplied panna by the same digit-sum rule the chart uses - sum the three digits, take % 10, with a guard rejecting anything that is not exactly three characters - and returns five fields: the winner list plus four aggregates, while each winner record carries nine fields.

That is a real analysis feature, and it is exactly as useful as it sounds: it is the tool an operator uses to see the exposure before declaring a result. It is also, by construction, not a forecast. Three more findings from the same method make the limits concrete. It scores five game types - single digit, jodi, and the three panna tiers. The other two of the seven bet types the platform settles, half sangam and full sangam, are not in its switch at all; the word "sangam" does not appear anywhere in that file. A what-if that cannot see a market silently reports it as having no winners. Its rate table has hard-coded fallbacks - 9.5, 95, 140, 280, 700 - used when configuration does not answer, which means the exposure figure it prints can be computed from rates that are not the ones the product is currently offering. And the pana inputs are optional: omit them and every bet short-circuits to zero payout, so the response reports zero winners and a total payout of nothing - while still counting your bets and summing your staked amount, because those totals accumulate before the comparison happens. A zero that means "I was not given a result" and a zero that means "nobody won" arrive as the same payload.

The ank derivation deserves one line too, because it is the same arithmetic the chart performs. calculateDigit sums the characters of the supplied panna and takes % 10, behind a guard that checks the string is exactly three characters long - but not that they are digits. Character.getNumericValue happily returns ten for A and twenty-four for O, so a mistyped panna produces a confident, wrong ank instead of an error. The chart never hits this, because its values come from the database. A what-if engine whose inputs come from a human keyboard can.

Here is the reframe this section exists to make. The honest form of "prediction software" is a what-if engine, and it is about money, not results. Feed it your stake set and a hypothetical outcome and it tells you what you would pay or collect; run it over every outcome and you have your payoff distribution, which is what the probability analysis actually computes by hand. What it cannot do - what nothing can do without an assumption about the generator - is tell you which outcome to feed in. Every product that claims otherwise is describing the second half of a sentence it has not written.

A Ten-Minute Test for Any Chart or Prediction Tool

The checklist below is the audit we ran on ourselves, converted into things you can observe without source access. Each line is phrased so that a tool can pass or fail it in front of you, and every one of them has a way to fail that we have seen in our own product.

Eight tests: six failures, one pass carrying a warning, one partial pass. That is the realistic score for an honest product, and it is a better outcome than the alternative - our app fails most of them by not having the feature, which is a fixable condition, rather than by shipping a number that looks like an answer. If you are evaluating software to buy or to trust, tests 1, 2, 4 and 5 are the ones that matter, because they are the four the vendor's own marketing cannot answer without changing the claim. The related app-level audit - what a Matka application's advertised features survive inspection - is done in full in the best-Matka-apps feature review, and the difference between a chart, a grid and a market's own conventions is in comparing all major Matka charts.

If You Want to Build the Tool Yourself, Here Is the Honest Specification

The unglamorous conclusion of this audit is that the analysis layer a player actually wants is small, and every one of its steps is checkable against published rules. If you build it - which takes an afternoon, since the arithmetic is trivial and the data is public - this is the specification that keeps you honest, in the order the steps have to run.

1. State the window before you state a number. Pull a fixed, declared span of dates and record it in every output. Do not scrape a chart page: pages cache for up to 180 seconds, and one of the feeds in this very product caps at 2,000 rows on page zero no matter what you ask for. Ask for dates; get dates.
2. Build your own denominators. A row is a draw. A blank, an off day, and a gap are not draws, and the product will not tell you which is which. Count declared results from your own fetch, not cells, and keep the excluded days in a separate list so you can report them.
3. Recompute the derived columns from digits, using the settlement rules. Ank = digit sum mod 10. Jodi = open ank concatenated with close ank. Red = digits equal or five apart. Do not accept a field called jodi from any feed that did not say which rule made it.
4. Print the fairness baseline next to every statistic. For a ten-way digit over n draws: expected count n/10, standard deviation sqrt(n x 0.09). At n=91 that is a mean of 9.1 and a standard deviation of 2.86 - so two standard deviations above the mean is a count of about 15, and one of the ten digits clears it on 33.6% of fair runs. A count of 15 is not a discovery; it is the shape of the noise. For a 100-way jodi: expected gap 100 draws, and an 8.11% chance any specific one is absent for 250.
5. Correct for looking. You tested ten digits, or 100 jodis, and reported the extreme. Use a 3-sigma mark at minimum: at n=1,097 that is 12.7%, and the expected hottest digit is 11.5%, so on your own deepest window nothing clears it.
6. Write your what-if, not your forecast. Take a hypothetical result, apply the rules, multiply by the published rates, and sum over your stake set. That calculation is exact, it is the thing that actually affects your money, and unlike a forecast it will still be true next draw.
7. Publish your provenance. Source, retrieval instant, window, declared-result count, and the corrections you know about. A tool that omits the first three has not measured anything; it has decorated a number.

That is the whole category. Rungs 1 through 4 and 5 are buildable and checkable; rung 6 needs a bias, the bias needs a sample, and the sample needs four decades per market for a half-point effect. The reading skills that make all of this legible start in the results-reading tutorial and how a jodi chart is organised; the record-keeping discipline that makes your data worth analysing is in finding an older result by date.

Frequently Asked Questions

Is there such a thing as good Matka chart software?

Yes - good chart rendering software, and there is a lot of it. A tool that lays out declared results completely, labels its window, keeps leading zeros intact, distinguishes a blank from an off day, and recomputes derived columns from digits using the rule that settles bets is doing something genuinely valuable. It is just not analysis in the sense the word is used in the advertisements. Every capability on the honest specification above is a rendering and bookkeeping capability.

Can software find a pattern in Matka results?

Software can find a ranking in Matka results, which is not the same thing. A ranking exists at every window depth by construction: over 91 fair draws the hottest digit is expected to appear 15.4% of the time and the coldest 5.3%, and a chart with ten digits and 50 pages will show you a two-sigma "leader" 99.9999% of the time. To find a pattern that survives honest thresholds, you need a real shift of at least 18% relative to a 10% base rate at the deepest window commonly offered - and to see a half-point shift you need about 14,400 draws, which is 39 years for one market that declares once a day.

Why do two charts of the same market disagree about the hot number?

Usually because of the window, and the disagreement is quantitatively expected, not a defect. In one real product the same market's declared results reach readers at five different depths - 1,097 dates on the grid page, 731 on the JSON feed, 91 on the hourly sibling, unbounded on the jackpot sibling, and a hard 2,000 rows on the paginated endpoint - and the simulation says the hottest digit over the last 91 draws differs from the hottest over the full 1,097 draws 80.1% of the time. Two people can compare the same market honestly and get different answers without either making a mistake.

Do push-notification or auto-updating charts make analysis more accurate?

They change when you see a number, not what it means. Freshness is a bounded delay with several layers - HTTP caching, server cache, polling - and it is documented properly in result time versus page update time versus archive date. The trap is subtler: a tool that updates faster than it corrects. If a published entry is later amended and the chart's aggregate is not recomputed, you now have a fresh, precise, wrong number - which is exactly the failure mode the correction-policy page is written about.

What is the difference between an "AI predictor" and the probability maths on this site?

A predictable quantity has a distribution you can write down; a prediction has a claim about the next draw. Across 306 server source files, this product contains no occurrence of "AI", "artificial", "machine learning", "forecast", "probability" or "trend" - so there is no forecasting engine here to compare against, and the vocabulary census above is what inspecting one actually looks like. What does exist is a digit-sum rule, a rate ladder and a payout calculation, and those are enough to derive everything knowable about your money before any result is declared. That derivation is done in the win-probability analysis; what a claimed accuracy figure would need to be checkable is in the 90% accuracy test.

Should I pay for chart or tip software?

Pay for rendering if rendering is what you need - completeness, correct labels, a stated window, and an export you can check. Do not pay for a ranking. The ranking layer costs nothing to reproduce, its baselines are one line of arithmetic each, and the version you can build in an afternoon comes with a denominator you chose deliberately instead of one inherited from a page cache. The one thing worth paying attention to is which rung the price is attached to. A tool charging for rung 3 is charging for a spreadsheet. A tool charging for rung 6 is selling something it cannot inspect, because no feed in this category is long enough to prove it.