An equity chart says “tested and ready,” but provides no explanation for its first trade. Begin with a smaller question: which signal, known when, produced that fill? Without an answer, the entire curve lacks a route back to the rules.
You can investigate without first learning a programming language. Put inputs, rules, hand-calculated expectations, and actual outputs beside each other. C4 supplies a familiar small example so you do not have to guess the strategy, data, and implementation at once.
What you will be able to do
- Give an AI assistant a sufficiently explicit input-and-output contract, resolving ambiguity first.
- Complete a small ledger, compare expected and actual fields on the same row, and classify discrepancies.
- Save a minimum review package and distinguish further investigation from an unverified tool or implementation.
Give the specification first and request a restatement
Supply rule version, verified sample, units and timing, expected checkpoints, and a prohibition on invented inputs. “Follow C4-S1-v1 without changing thresholds, quantities, costs, or execution time” is more testable than “implement a trend strategy.”
C4 starts with $1,000 and zero shares. A daily close strictly above $11 sets a twenty-share target; otherwise the target is zero. Adjust at the next listed trading day's open. Each successful order costs a fixed $1. If cash is insufficient, reject the whole order without a fee.
There are no external flows, dividends, splits, tax, interest, or slippage, and settlement delay is not modeled. This is not an abbreviation of C2's monthly ETF rule. Their costs, targets, and schedules cannot be exchanged because both involve a signal.
Ask the assistant to restate conditions and identify genuine unresolved points. “Do you understand?” followed by agreement does not establish identical interpretations. Resolve conflicts and confirm a version before implementation, rather than choose whichever output looks best and rewrite the definition afterward.
Specify outputs too: input date, signal time, target, pending order, actual fill, fee, cash, shares, valuation, and equity for every day. Intermediate fields distinguish an implementation that follows the process from one that reaches the endpoint by coincidence.
CFA Institute's diligence guidance discusses understanding and checking quantitative-model assumptions, limitations, and uses.[1] Applying that principle here means reconciling rules to ledger behavior. A technical explanation alone does not perform the check.
Save expectations before viewing the output
The original synthetic prices are D1 open 10/close 10, D2 10/12, D3 13/11, D4 10/10, and D5 10/10, in dollars. Rows are consecutive listed trading days from the fixed C4 materials, not market history.
Hide the tool output and fill three checkpoints: the target after D2 closes; cash and closing equity after the D3 purchase; and cash after the D4 sale. Preserve that first calculation before running. If you already know the answers, label a reconstruction as retrospective checking, not a forecast made before viewing results.
After D2, the target is twenty shares, with the order waiting for D3. Buying twenty at D3's $13 open costs $260 plus $1, leaving $739. At the $11 close, stock value is $220 and equity $959. That close does not satisfy strictly above $11, so the next target is zero. D4's sale brings $200 less $1, leaving $938. No subsequent trade occurs.
These checkpoints diagnose different links. The first cash change checks quantity and cost; closing equity checks valuation; the next cash change checks exit time and fee. A correct endpoint does not establish correct intermediate behavior, because errors can offset.
Check the same row in a usable ledger
Use the supplied C4 interactive workbook in software supporting its XLSX formulas. No code modification is required. Yellow cells with blue text identify inputs; preserve formulas and expected answers elsewhere. The case-material index also provides original CSV inputs and the specification. Check fields, values, and order before importing them elsewhere.
Find D3 in the calculated ledger: cash 739, twenty shares, stock value 220, and equity 959. For D4, verify a fill of −20 shares, fee 1, cash 938, and zero shares.[2] Compare those saved actual fields with your own expectations, rather than examine only an ending-value chart.
Change the per-order fee in B8 from 1 to 2. D3 should show cash 738 and equity 958, with ending equity 936. Restore 1 and check that 938 returns. Baseline-difference fields compare against original inputs; a deliberate fee variant should not be failed merely for differing from the baseline answer.
Then change only initial cash in B7 to 200. The unaffordable order should leave $200 and no shares, rather than resize itself. Preserve each single-change test separately so a difference has an identifiable cause.
Save another XLSX retaining formulas, close and reopen it, then repeat the fee change and restoration. If sharing a numerical snapshot, use the software's UTF-8 CSV export and reopen it to inspect D3 and D4. CSV preserves values, not the workbook formulas.
Keep the delivered original as a recovery point. If formulas fail to refresh, formats are unsupported, or required inputs are missing, stop at unverified status. Replacing formulas with values that match expected answers would remove the calculation being checked.
The existing author-side record reports spreadsheet-engine tests of these variants, missing-input propagation, XLSX export and reopening, and CSV snapshots; the repository calculator also matches the original ledger. Native Excel/WPS menus and compatibility were not tested. Complete the checks in your own software. The recorded evidence concerns a fixed mechanism, not an independent strategy implementation or CoTrading product acceptance.
If an import fails, retain the error and field information. Check supported CSV layout, numerical formats, and required columns. Use another checkable route or stop at reading the supplied case if needed. Deleting dates or fees to make an import succeed changes the task. An old chart cannot serve as a new run's output when intermediate values are unavailable.
Diagnose two different wrong results
Prepared output A claims the original C4 rules but shows D3 cash 759 and equity 979. Its trade record buys twenty shares at D2's $12 close. The arithmetic can be correct while the execution rule is wrong. C4 requires D3's $13 open; moving the fill earlier improves the result by violating the specification.
Prepared output B buys twenty at D3's $13 open but shows fee 2, cash 738, and equity 958. Relative to the original expectation, each is $1 lower where appropriate. Inspect fee settings and detail. If two components each charge the same $1 buy fee, it is duplication, not merely more conservative realism.
There is also an offsetting error. Omit the $1 buy fee but undervalue the position by $1. Cash becomes 740 and stock value 219, totaling the expected equity of 959. Both component fields are wrong. Checking only equity would miss the discrepancy.
These are deliberately constructed diagnostic outputs, not tests of real products. Numbers narrow the investigation; input, configuration, and fee records establish its cause. If B genuinely uses a newly authorized $2-fee version, first determine whether that version matches this frozen task. Do not simply change the expected answer to make it pass.
Repair one verified issue at a time. Restore next-open execution while keeping inputs and costs fixed, then recheck affected signals, orders, and balances. Changing data, parameters, and fees together would make the improved endpoint difficult to explain.
Separate four kinds of problem
A data problem means inputs violate the agreement, such as missing prices or mixed units. Check source and fields without fabricating replacements. Rule ambiguity means the written contract permits multiple answers. Fix the specification before asking an implementer to choose.
An implementation error means clear rules and valid inputs were handled incorrectly: inclusive rather than strict comparison, duplicate fees, or same-close execution. A tool limitation means the product cannot import the required field, represent the order, or export the necessary record. That missing capability is not a completed implementation with an inconvenient detail omitted.
For import errors, compare the original version, names, values, and times with actual product documentation. If no supported format exists, record incompatibility rather than repeatedly altering inputs until the original question disappears. For runtime errors, preserve settings, inputs, error text, and retry conditions—not just a later successful chart.
CFA Institute's backtesting overview connects assumptions, rules, portfolio formation, and evaluation.[3] Generated code, absence of runtime errors, and agreement between two models each leave behavior checking unfinished.
What if the tool supplies only a curve?
Request signals, orders, fees, cash, and holdings, or matching-date intermediate values. A chart may permit a rough directional comparison with hand expectations; it cannot establish the full relationship between signal, fill, and cost.
An external checkable path can reproduce the same fixed task, using another tool that exports a ledger. Preserve its inputs, settings, and result. Similar-looking curves alone are not a match. External reconstruction checks the mechanism without automatically giving the original tool evidence it never supplied.
If records remain unavailable, report: “The supplied mechanism exercise is complete; independent implementation acceptance for this tool has not passed.” This does not establish that the strategy is ineffective. It says evidence is insufficient to identify what was implemented. Five-day C4 results cannot replace C2's full data and historical research.
Locate the discrepancy yourself
Explanation question: Why is an ending value of 938 insufficient to establish correct implementation?
Application question: Output A shows cash 759 and a $12 fill; B shows fee 2 and cash 738. Which rule and record should be inspected first for each? Save a discrepancy table before reading the guide.
Offsetting errors can preserve an endpoint, so check signal time, orders, fees, and daily state. For A, investigate execution time and price source. For B, inspect the fee rule and detailed charges. Keep the original inputs; do not rewrite the contract to accommodate the output.
A rejected order can be the right answer
Change only initial C4 cash from $1,000 to $200. All other inputs and rules remain. D2 still produces a twenty-share target. To avoid an error, an assistant automatically buys fifteen shares and claims completion. What should happen at D3's open, and what cash and holdings should remain?
Twenty at $13 plus the fee requires $261, exceeding $200. The frozen rule rejects the entire order without charging. D3 therefore leaves cash 200 and shares zero. Its close of 11 gives a zero target; there is no existing position to sell afterward.
Automatic resizing to fifteen shares is another, unauthorized insufficiency policy even if its arithmetic balances. This single-factor behavior check leaves the signal unchanged. Save it separately from the original ledger; it is neither the C4 baseline return nor a new profitable strategy.
Save the minimum review package
Include original input and version, T05 specification, T11 AI task, model or tool identifier, run date, critical settings, hand expectations, actual intermediate table, discrepancy location, and reasons for revisions. Source-code edits are unnecessary for those records. Exclude account passwords, keys, and unrelated sensitive information.
For each difference identify input row, rule, output field, and checkpoints affected by a retry. Finish with an explicit scope: mechanism exercise only, fixed-input implementation passed, or gaps remaining for an independent task. Another person should be able to follow the same package without guessing defaults from your verbal explanation.
Replace completion labels with inspectable behavior
Freeze inputs and rules, ask for a restatement, save expectations, then compare actual signals, orders, and balances on the same row. Classify data, ambiguity, implementation, and tool problems before changing one verified cause.
Intermediate tables and versions support more than an attractive curve. Mark unexported or unchecked behavior honestly. A successful fixed synthetic ledger still leaves real data, long-term evaluation, and operation with separate evidence requirements.
References
- CFA Institute: Standard V(A)—Diligence and Reasonable Basis. Quantitative assumptions, limitations, and appropriate checking; not a legal qualification imposed on every individual reader.
- C4 fixed materials and calculator record. Input, specification, expected ledger, workbook, and recorded author-side tests; not acceptance of a different tool.
- CFA Institute: Backtesting & Simulation. Public 2026 overview and summary; paid text not reviewed.
Sources checked October 30, 2026; workbook-engine evidence retains its recorded October 29 author-side scope. No native desktop or real long-term C2 run is claimed. AI-assisted draft; independent AI full-text and bilingual review is complete. Human financial review and target-reader testing have not been conducted and are not scheduled for this production round.