When a Skill Becomes a Method

In anthropics/financial-services, a skill becomes valuable when it does more than name a task. It must define what enters the workflow, how the input is transformed, which evidence supports the transformation, what can go wrong, and how another professional can inspect the result. This chapter focuses on that mechanism. DCF modeling, comparable-company analysis, ledger reconciliation, and KYC evaluation look unrelated on the surface, but the repository gives them a common discipline: sourced inputs, explicit operations, bounded uncertainty, and a reviewable output.

Models and research: making calculations inspectable

The DCF skill treats spreadsheet construction as a reasoning problem, not as the last formatting step after a calculation. It requires raw historical or market inputs to remain distinguishable from projections and derived values. Projection cells should contain live formulas rather than numbers calculated elsewhere and pasted into the workbook. Hardcoded inputs are documented with source comments. Scenario assumptions are organized so that a selected case feeds a central set of formulas, and sensitivity tables are populated with formulas rather than left as a manual exercise.

Each rule addresses a failure mode that is easy to miss in a polished workbook. A hardcoded output can look correct while silently refusing to update when an assumption changes. A missing source comment makes a number impossible to challenge efficiently. A scattered scenario condition can make it unclear which case a projection is using. A sensitivity table that contains placeholders gives the appearance of analysis without actually showing how valuation responds to assumptions. The skill's structure makes these weaknesses visible before a reviewer has to infer them from a final number.

The same logic appears in the comparable-company method, but the central risk is comparability rather than projection mechanics. The skill prioritizes structured institutional sources when they are available and discourages web search as the primary source for institutional analysis. It asks the analyst to define the question first, then choose a focused set of operating and valuation metrics. Multiples should reference the operating metrics already entered rather than duplicating raw data in a second place. Statistical summaries such as medians and quartiles describe the distribution of the peer set, while sanity checks ask whether the companies really belong in the same comparison.

That is a method because it connects a choice to its consequence. If a peer set includes companies with different business models or mismatched time periods, a clean median does not repair the comparison. If a number comes from an uncertain source, an attractive table does not turn it into institutional evidence. The skill does not guarantee a sound investment conclusion; it creates a structure in which a reviewer can see the peer definition, source hierarchy, metric choice, and calculation path.

The modeling layer also separates mechanical integrity from economic judgment. The audit skill can identify broken formulas, inconsistent ranges, hardcodes inside calculations, unit mismatches, broken cross-sheet links, balance-sheet failures, cash-flow tie-out failures, and unreasonable model behavior. Those checks are valuable because a workbook can be internally inconsistent. But a workbook can also balance and still contain an implausible growth assumption or a weak comparison. The repository's method therefore needs both formula-level checks and professional review of the assumptions that the formulas express.

The DCF method makes that separation visible through review checkpoints. Inputs are shown before projections are built; projected revenue is checked before margins and free cash flow are extended; the cost of capital is examined before discounting; and the valuation bridge is reviewed before sensitivities are added. The exact sequence is less important than the causal idea: a bad assumption discovered early is cheaper to correct than a bad assumption embedded in every downstream output. Incremental review turns the model from a black box into a chain of claims that can be challenged.

Reconciliation: explanation starts with normalization

The GL reconciliation skill shows the same pattern in an operational setting. It does not begin by asking a model to explain why two ledgers differ. It first requires both extracts to be normalized to a common key and common comparison columns. Dates, amounts, and identifiers must be made comparable before equality can mean anything. The two sides are then matched at the lowest grain they share, and each row is placed into a bucket: matched, amount break, quantity break, timing break, GL-only, or subledger-only.

This ordering matters because a difference can be created by representation rather than by an economic event. A date format, sign convention, identifier spelling, or unit mismatch can make equal records appear different. Conversely, joining at too high a level can hide the transaction that caused a material variance. Normalization and matching reduce those false explanations before the workflow asks for a likely cause.

The skill also keeps cause separate from proof. A timing, foreign-exchange, mapping, duplicate, fee, accrual, or data-quality label is a hypothesis for the resolver, not a conclusion. The break report carries both sides' values, a bucket, a likely cause, and a note; material items can then go to a deeper break-trace method. This is a small but important form of uncertainty management. The workflow is allowed to be useful before it is certain, provided the status of the explanation remains visible.

The result is more reviewable than a paragraph saying that the ledgers “did not reconcile.” A controller can inspect the key, the values on each side, the tolerance, the bucket, and the evidence that supports a root-cause claim. The method turns a vague symptom into an ordered path from representation to match to hypothesis to verification.

The tolerance is part of that explanation, not a hidden implementation choice. An amount that differs by a permitted rounding tolerance is not the same kind of event as a missing position or a quantity mismatch. A classification can route work efficiently, but it must remain proportional to the evidence. That is why the skill describes likely causes as hypotheses and sends material breaks to a deeper trace rather than letting an initial label become a final diagnosis.

KYC: authority and evidence must remain separate

The KYC rules skill applies the same discipline where the source material may contain sensitive identity information and the consequence of a false clearance is high. It distinguishes the firm's rules grid—a trusted source—from an applicant record derived from untrusted documents. The record is something to which the rules are applied; it is not allowed to issue instructions about how it should be handled.

The skill asks for a risk rating built from defined factors such as jurisdiction, applicant type, ownership opacity, politically exposed person exposure, sanctions or adverse-media results, and source-of-funds clarity. It then checks required documents, produces one outcome for every applicable rule, cites the rule that drove the outcome, and assigns a disposition such as requesting documents or escalating for enhanced due diligence. The final state is intentionally limited: the skill never approves. A clear result still depends on the specified conditions, and otherwise the case is routed for review.

The rule citation is as important as the rating label. “High risk” without the factors and rule outcomes behind it is difficult to contest or update. A cited rule lets a reviewer distinguish a missing document from a screening hit, a jurisdictional factor from an ownership problem, and a genuine failure from an incomplete record. It also makes a change in the firm's rules grid more consequential and more manageable: the method can show which outcome changed and why.

The KYC example clarifies a broader principle. Evidence can be relevant without being authoritative. A formation document may contain useful legal-name or ownership data, but it does not get to redefine the firm's rules. A screening result can be a signal, but it does not become a final risk decision merely because a workflow has formatted it. The method preserves the distinction between extracting facts, applying policy, recommending a disposition, and approving a client.

The required-document check makes the same distinction operational. A missing or expired document is not silently converted into a pass, and an escalation reason is tied to a rule or screening result rather than to an unexplained score. This produces a case that a compliance reviewer can reopen: the reviewer can see which field was extracted, which rule applied, which item is missing, and why the workflow routed the packet instead of clearing it. The output is useful because it preserves the path from evidence to disposition.

One pattern, different financial consequences

These methods share an architecture without sharing a conclusion. In a DCF, the key control is the connection between sourced assumptions and live calculations. In comparable-company analysis, it is the comparability of the peer set and the consistency of the metrics. In reconciliation, it is the sequence from normalized records to classified breaks and verified causes. In KYC, it is the separation between untrusted evidence, trusted rules, and a human compliance decision.

The portable pattern can be stated as five questions:

  1. What is the input, and how trustworthy is it? A market-data feed, internal ledger, and applicant document do not have the same status.
  2. What transformation is being performed? It may be a formula, a peer comparison, a join, a rule evaluation, or a screening operation.
  3. What makes the transformation inspectable? Source comments, consistent definitions, evidence references, tolerances, and rule citations serve that role.
  4. What remains uncertain? A valuation assumption, a peer choice, a likely break cause, or a screening hit may need different kinds of review.
  5. What is the bounded output? It may be a model, table, report, or escalation packet, but it is not automatically the final decision.

That pattern is more useful than a claim that every financial workflow can be standardized. The consequences are different, and the method must respect those differences. A tolerance that helps classify ledger differences has no place in a DCF. A rule citation cannot substitute for a market-data source. A sensitivity table cannot decide whether a KYC case should be approved. Portability means the discipline of explicit inputs and checks can travel; it does not mean the domain logic can be flattened.

flowchart LR A["Sourced input"] --> B["Domain transformation"] B --> C["Source or rule reference"] C --> D["Integrity or sanity check"] D --> E["Bounded work product"] E --> F["Professional review"]

The sequence also explains why method files contain more than their headline formulas or rules. A good method specifies when to validate inputs, what not to hardcode, how to represent assumptions, what to do with missing data, and where to stop. Those details are not procedural decoration. They are how a reviewer can tell whether the output is a faithful application of the method or merely a plausible-looking result.

What a portable method cannot guarantee

The repository's skills are first-party operating instructions and templates, not empirical proof that every future execution will be correct. A workbook can satisfy formula conventions while using an assumption that deserves challenge. A peer analysis can cite an institutional source while selecting a poor comparison set. A reconciliation can classify every difference while still receiving incomplete extracts. A KYC result can pass schema validation while the extracted field is wrong.

The method files also include environment-specific conventions. Spreadsheet creation may differ between a live Office session and a standalone file. A firm may use a different template, data provider, approval threshold, or definition of a metric. Those variations do not invalidate the underlying discipline, but they mean the implementation must be adapted and rechecked rather than copied as universal law.

This is the main reason a skill should travel with its controls. If a firm copies only the visible action—“build a DCF,” “reconcile the ledger,” or “screen the packet”—it carries away the least reliable part of the method. If it copies the evidence hierarchy, assumptions, transformation rules, uncertainty labels, integrity checks, and stopping conditions, it has a chance to preserve the reasoning that makes the output useful.

The next step is to see how named agents order these local methods into a complete lifecycle. A skill tells the workflow how to calculate, compare, classify, or evaluate. An agent decides when to invoke that method, what comes before it, what follows it, and which artifact must be reviewed before another action is allowed.

References