Working on the GLP-1 market analysis was a case study in how fast a single drug class can reprice an entire adjacent sector. The direct beneficiaries — the manufacturers — were the obvious trade. The more interesting moves happened one and two steps removed: snack food companies, gym chains, and medical device makers all saw their multiples shift on the market’s revised expectations for future demand, long before any of them reported a single dollar of actual impact.

This is the part of narrative-driven repricing that a pure discounted cash flow model handles badly. A DCF wants a specific, quantified change in the cash flow forecast. But markets do not wait for that specificity — they price the distribution of plausible outcomes as soon as the narrative becomes credible, and they revise again as the narrative gets more or less credible, independent of any single earnings report.

What I took from building the analysis is that the second-order names are usually mispriced in both directions at different points in the cycle — first overreacting to the threat or opportunity, then overcorrecting once the initial narrative proves too simple. The companies that get quietly repriced correctly are the ones where someone did the unglamorous work of mapping second-order exposure before it was obvious.

Narrative risk is real risk. Treating it as noise until it shows up in guidance is a way of guaranteeing you are always late to it.

Studying risk and audit frameworks reframed how I think about financial statement quality. The audit process is not primarily about catching arithmetic errors — computers do that reliably. It is about testing whether the controls around a number are strong enough that the number can be trusted without independently rebuilding it from source documents every time.

This is a different mental model than the one most valuation work uses. An analyst asks “is this number right.” An auditor asks “what has to be true about this company’s process for this number to be reliably right, quarter after quarter, without me checking.” The second question is more useful for spotting risk, because control weaknesses tend to show up long before the numbers themselves go wrong.

I started applying this to the way I evaluate management teams generally, not just their filings. A company that changes its revenue recognition policy, rotates auditors unexpectedly, or has a pattern of late filings is showing you a control problem, and control problems compound. They rarely stay contained to the one line item that first drew attention.

The lesson generalizes past finance: any system, financial or otherwise, is only as trustworthy as the weakest control governing the inputs that feed it. Auditors are trained to look for that weak link first. Most of us are trained to look at the output and assume the process behind it was sound.

The instinct in most valuation work is to treat the bid-ask spread as friction — a cost to be minimized, not a signal to be read. Studying sales and trading changed that. A widening spread on a name is often the earliest available marker that liquidity providers are repricing uncertainty, well before that uncertainty shows up in an earnings estimate or a credit rating action.

This is easy to miss if your background is entirely fundamental analysis, because spreads live in market microstructure, a different discipline with its own vocabulary — inventory risk, adverse selection, order flow toxicity. But the underlying idea translates directly: market makers are running their own real-time credit and volatility model on every name they quote, and the spread is the visible output of that model.

I started treating spread behavior the way I treat a red flag in a filing: not decisive on its own, but a reason to look harder. A stock trading at a persistently wider spread than its peers, with no obvious news catalyst, is telling you something about how professional risk-takers view the tail outcomes, not just the expected one.

None of this replaces fundamental work. But a valuation that ignores what the market’s most information-sensitive participants are doing in real time is missing a data source that updates faster than any filing ever will.

Studying tax and transaction advisory changed how I read deal announcements. Two acquisitions with identical purchase prices and identical target companies can produce wildly different after-tax outcomes depending on whether the deal is structured as a stock purchase or an asset purchase, whether a section 338(h)(10) election is made, and how net operating losses survive the change of control. None of that shows up in the headline multiple.

The part that is easy to miss as a student is that tax structuring is not a footnote to the deal — it is frequently the reason the deal happens at all. A buyer willing to pay a slightly higher price in exchange for a step-up in asset basis can create more value through depreciation shields than through any operational synergy slide in the deck. Sellers who understand this hold real negotiating leverage on structure, not just price.

I noticed the same pattern in smaller transactions I studied in client work outside pure M&A: even a straightforward acquisition of a small services business gets reshaped by how earnouts are taxed versus how upfront consideration is taxed. The mechanics scale down; the logic does not change.

Most valuation training teaches you to get to enterprise value and stop. The tax layer is where a meaningful share of that value either survives or evaporates, and it rewards exactly the kind of patient, structural thinking that headline multiples discourage.

The Bloomberg Terminal certification is a good crash course in function codes and a bad substitute for understanding why the data looks the way it does. Every screen on the terminal is an aggregation choice someone made — which pricing source to default to, how to handle a thinly traded bond, what counts as “consensus” when only four analysts cover a name. Learning the keystrokes teaches you to retrieve data. It does not teach you to doubt it.

What actually changed how I use the terminal was running into disagreements between it and a company’s own filings. A reported EBITDA figure from a data vendor rarely matches a hand-built EBITDA from the 10-K line items, and the gap is never random — it is usually a stock-based compensation add-back or a one-time charge someone decided was recurring, or the reverse. The terminal gives you the vendor’s judgment call, dressed up as fact.

This matters more as more finance work gets automated. If an agent or a script pulls a multiple straight from a terminal API without knowing which adjustments are baked in, it inherits every judgment call silently. I now treat any terminal-sourced number as a starting hypothesis, not an input.

The certification is worth having because fluency with the tool is table stakes. But the actual skill it is trying to certify — knowing when to trust the screen — is not something a multiple-choice exam can test.

I built the Orcen Capital auto valuation kit expecting the hard part to be the DCF math. It was not. The hard part was getting clean, comparable inputs out of ten different filing formats, three different fiscal year conventions, and at least one company that changed its segment definitions mid-year without saying so clearly. By the time the numbers reached the actual model, eighty percent of the work was already done.

This reframes what a valuation model is. Most finance courses teach the formula as the product: discount the cash flows, apply the multiple, sanity-check against comps. But a formula applied to bad inputs just produces a confident wrong answer faster. The valuation kit spends most of its code on parsing, normalizing, and flagging inconsistent inputs — the unglamorous plumbing that never shows up in a case study.

Once the pipeline is solid, the valuation itself becomes almost boring, which is exactly the point. A model that requires heroics to run correctly is a model that will eventually be run incorrectly by someone in a hurry. I would rather have a valuation kit that is slow and impossible to misuse than one that is fast and easy to get wrong under deadline pressure.

The broader takeaway applies past finance: any analytical tool is mostly data engineering wearing a finance costume. The interesting question was never “what is the right multiple.” It was “how do I trust the number before the multiple even gets applied.”

When I built the Company Health Red-Flag Scanner, the hard part was not the scoring logic. It was deciding which ratios lie. Current ratio looks fine right up until a company times its receivables collection to land two days before the balance sheet date. Interest coverage looks fine right up until a covenant amendment quietly resets the denominator. The scanner does not trust any single ratio — it triangulates. A deteriorating cash conversion cycle plus flat gross margin plus rising days sales outstanding is a different signal than any one of those alone.

What surprised me is how much of financial distress shows up in the footnotes before it shows up in the numbers. Related-party transactions, changes in revenue recognition timing, auditor language that softens from “unqualified” to “unqualified with an emphasis of matter” — these are cheap to read and expensive to model, so most screens skip them. I built mine to flag the language, not just the arithmetic.

Running it across a few hundred companies taught me that most red flags are not fraud. They are ordinary stress: a customer concentration problem, a refinancing wall eighteen months out, a management team optimizing for the metric analysts watch instead of the one that matters. The scanner does not diagnose intent. It just makes the stress visible earlier than a quarterly earnings call would.

The real lesson was about tooling, not accounting. A rule-based scanner will always miss novel failure modes. But it does something a human analyst covering forty names cannot: it never gets bored and it never skips the tenth company on the list.

In finance, optionality is the value of having choices you aren’t forced to exercise. The same idea, applied to a career, is one of the more useful frames I’ve found — and one most early planning quietly ignores in favor of committing to a single narrow path.

Building at the intersection of finance and AI is, in option terms, deliberately holding several strikes at once. It keeps engineering, fintech, and finance roles all live rather than foreclosing on any of them prematurely. That breadth costs something now — a less tidy story, a slower-looking specialization — in exchange for the freedom to move as the landscape changes.

The point isn’t to avoid ever committing; options you never exercise expire worthless. The point is to keep the valuable ones open until you have enough information to commit well. In a field shifting as fast as this one, the ability to change direction without starting over is worth paying for — and like any option, it’s most valuable exactly when uncertainty is highest.

Sending cold emails is an exercise in humility and, quietly, in information theory. Most go unanswered. But the pattern of which ones land teaches you something you can’t learn from a guide: the difference between noise and signal in how you present yourself.

The messages that work aren’t the polished, generic ones. They’re specific — clearly written by someone who did the homework, aimed at this person for a real reason, asking for something concrete. Genericness is noise; specificity is signal, and the reply rate is a brutally honest measure of which one you actually sent.

That lesson generalizes well past email. In a world drowning in low-cost, generic output, specific and genuine stands out precisely because it’s expensive to fake. Every unanswered message was feedback pointing the same direction: be more particular, do more homework, earn the reply. Learning to send real signal, not more noise, turned out to be worth far more than any single introduction it produced.

Ambition tends to reward for scale — the big project, the grand plan, the thing that will matter once it’s done. But grand plans have a way of never being done, and a graveyard of impressive unfinished work teaches you almost nothing except how to start.

Finishing is a separate skill from starting, and it’s the rarer one. A small thing carried all the way to done — shipped, closed, actually complete — teaches you the whole arc: the unglamorous last mile where the real problems hide, the discipline of calling something good enough. Starters are common; finishers compound.

So I’ve made a habit of completing small things rather than perpetually beginning large ones. Each finished piece is practice at the ending, the part most people skip. The daily essay is exactly this: modest in scope, but shipped every day. The size is beside the point — the reps at finishing are the point, and they add up faster than any single big thing would.

The center of any established field is crowded. The problems are well-defined, the experts are numerous, and the returns to being one more competent person there are shrinking. The boundary between two fields is a different place entirely — less crowded, less mapped, and far more interesting.

At the seam between finance and AI, the useful move is often just translation: taking an idea that’s obvious to one side and carrying it to the other, where it isn’t. Neither community has fully absorbed the other’s tools, so the person fluent in both can see connections invisible from inside either. Scarcity of that fluency is exactly where the leverage lives.

That’s a deliberate bet on my part rather than an accident of interest. Going deep enough in two fields to work at their intersection is slower than specializing in one, and for a while it looks less legible. But the boundary is where the unclaimed problems are, and being early to a seam beats being one more voice at a crowded center.

Studying far from where I grew up came with obvious costs — visa constraints, distance, the friction of always being slightly outside the default. It would be easy to file all of that under disadvantage. But the same conditions quietly trained a way of working I now rely on.

Being the outsider means you can’t coast on assumed context. You question things locals take for granted, notice conventions that are actually just habits, and build for a wider set of users because you were never inside the narrow default to begin with. Not fitting the mold makes the mold visible, and visible things can be redesigned.

It also raises the bar on self-reliance. When the safety nets are thinner, you learn to figure things out and to build your own leverage rather than wait for it to be handed over. I wouldn’t romanticize the hard parts, but the resourcefulness they forced is real, and it shows up in the work. The constraint became a habit of mind, and the habit outlasts the constraint.

Transcripts measure a narrow band of ability: how well you performed on defined problems under supervision. That’s real, but it leaves out the thing that turns out to matter most once the supervision ends — the ability to make progress on a problem no one has scoped for you.

School hands you well-formed questions with known answers. Actual work hands you a vague dissatisfaction and asks you to turn it into something. Nobody grades the intermediate steps, and there’s no answer key. The skill of navigating that ambiguity — deciding what to build, learning what you need as you go, knowing when it’s good enough — is invisible to any transcript.

I’ve learned it the only way it seems learnable: by building things that weren’t assigned. Every self-directed project is practice at operating without a rubric, and that practice compounds into the exact capability the transcript can’t capture. The grades open some doors; the unscoped work is what determines whether you can do anything once you’re through them.

Learning privately is comfortable. You can stay in the phase where everything is tentative and nothing is finished, indefinitely. Learning in public removes that comfort, and the discomfort is precisely the point.

When you commit to shipping something others will see, you can’t hide behind almost-done. The work has to reach a state you’re willing to stand behind, which forces decisions you’d otherwise defer forever. Publishing is a deadline you impose on yourself, and deadlines are where half-formed things finally get finished.

It also invites correction, which stings and helps in equal measure. Someone points out a flaw, and you learn faster than any amount of solo study would have taught you. The exposure is the mechanism — being seen is what converts passive learning into the kind that actually sticks. I’d rather be usefully wrong in public than comfortably vague in private.

Writing a short essay every day isn’t a content strategy. It’s a thinking discipline. The act of putting an idea into clear prose is a stress test the idea has to survive, and plenty of things I was sure I understood didn’t make it through the first paragraph.

You can hold a fuzzy notion in your head indefinitely and feel like you know it. Writing removes that comfort. The sentence either says something specific or it doesn’t, and the gap between a real understanding and a vague impression becomes impossible to ignore once you try to make it legible to a stranger.

So these essays are partly for a reader and mostly for me. They force me to actually finish a thought instead of collecting half-formed ones. If a piece reads clearly, it usually means I finally understood the thing well enough to explain it — and if it doesn’t, that’s useful information too. Writing is how I find out what I actually know.

A resume is a claim: here is what I say I can do. A portfolio is evidence: here is a thing I built that you can open and inspect. As it gets easier to make claims and harder to trust them, the balance of proof has shifted decisively toward the evidence.

This is freeing if you take it seriously. You don’t need permission or a prestigious title to demonstrate capability — you need to build something real and put it where people can see it. The work argues for you in a way a bullet point never can, and it argues even while you sleep.

That conviction is why I’ve put so much into this site. Every project here is something someone can actually examine, not a phrase on a page. The resume still opens doors, but the portfolio is what convinces the person on the other side that the claims were true. Increasingly, showing beats telling — so I try to have something to show.

Early on, the appealing strategy is to sample widely — a bit of everything, so no door is closed. It feels safe. But breadth without depth tends to produce a long list of things you’ve touched and nothing you can actually do, and that list impresses no one for long.

Depth behaves differently. Push far enough into one thing and you stop learning facts and start learning how the thing really works — the failure modes, the judgment calls, the parts the overview left out. That kind of understanding transfers. Someone who has gone deep once knows how to go deep again, in a new domain, faster.

I’ve tried to build at the intersection of finance and AI not by skimming both but by going far enough into each that they start informing each other. The compounding shows up at the seam, where a genuine understanding of one field reframes a problem in the other. Breadth is a collection; depth is a capability, and only one of them keeps paying you back.

Latency is usually filed under user experience — a slower system is a more annoying one. For autonomous agents, slowness crosses over into something more serious: it changes what the agent is reasoning about, because the world can move while the agent is thinking.

An agent that reads a price, deliberates for thirty seconds, and then acts may be acting on a state that no longer exists. In any domain where the underlying data changes — markets, inventory, live systems — accumulated latency across a chain of steps means decisions land in a world that has already shifted. Slow isn’t just sluggish; it’s occasionally wrong.

So I treat latency as a correctness constraint, not just a performance metric. That means shortening chains, caching what’s stable, and being explicit about how fresh each input has to be for a decision to remain valid. For an agent operating in a moving environment, speed isn’t a luxury on top of accuracy — past a point, it’s part of what accuracy means.

When an agent misbehaves, the reflex is to blame the model or rewrite the prompt. Often the real culprit is upstream: the agent was reasoning correctly over data that was stale, malformed, or missing the piece it actually needed.

An agent is only as good as what it can see. Give it an outdated document, an inconsistent record, or a tool that returns partial results, and it will produce a confident, well-argued, wrong answer. From the outside that looks like a reasoning failure. Underneath it’s a data failure the model faithfully reflected.

This has changed how I debug. Before touching the prompt, I inspect exactly what the agent received at the moment it went wrong. More often than I’d like, the fix is in the pipeline, not the intelligence — a better retrieval, a validation step, a freshness guarantee. Treating agent behavior as downstream of data quality solves a surprising share of what first looks like the model simply being dumb.

Human-in-the-loop often gets treated as an admission of failure — the thing you keep until the agent is good enough to remove it. That framing quietly leads to worse systems, because it aims at the wrong target.

For consequential actions, human review isn’t a crutch; it’s the correct architecture. The question is not whether a human is involved but where. A well-placed checkpoint before an irreversible step adds enormous safety at almost no cost. A badly placed one that interrupts every trivial move adds friction and trains people to click through without looking.

So I design the checkpoints deliberately, mapping which actions are reversible and which aren’t, and putting the human exactly where a mistake would be expensive and hard to undo. Done well, the goal isn’t to remove the human — it’s to make their attention count, spending it on the few decisions that genuinely need judgment and nowhere else.

Larger context windows get sold as a reason to stop worrying about what you include. Just put everything in and let the model sort it out. In practice, a context window is a budget, and spending it carelessly degrades the very reasoning you were trying to help.

Models don’t attend to a hundred thousand tokens as evenly as they attend to a thousand. Bury the critical detail in the middle of a huge dump and it competes with noise for attention. More context can mean worse answers, because the signal-to-noise ratio, not the raw capacity, is what drives quality.

I treat context assembly as an active design decision: what does the model need for this step, in what order, and what should be left out. Curating a tight, relevant context usually beats stuffing a large one. The window is a resource with real limits, and spending it deliberately is one of the highest-leverage things you can do for an agent’s reliability.

The common way to constrain an agent is to tell it what not to do in the prompt. Don’t touch production. Don’t spend over a threshold. Don’t delete anything. This works until the one time it doesn’t, and prompts are the weakest possible place to enforce a rule.

Instructions are suggestions the model usually follows. Under an unusual input or a long enough context, following degrades. A rule that matters shouldn’t depend on the model choosing to honor it in the moment — it should be enforced by the environment, where compliance isn’t optional.

So I put hard limits in the tools and the surrounding system, not the prompt. If an agent must never exceed a spending cap, the tool refuses the call above the cap, full stop. The prompt still explains intent, because clarity helps — but the guarantee lives in code. Prompts are for guidance; environments are for guarantees, and confusing the two is how agents cause real damage.

Language models are probabilistic by nature, and that’s often a strength — it’s where flexibility and fluency come from. But for many real workflows, unpredictability is a liability, and determinism doesn’t arrive on its own. You have to build it in.

The instinct to fix this by lowering temperature only goes so far. Real determinism comes from structure around the model: constrained output formats, validation that rejects anything off-spec, and deterministic code handling the parts that must be exact. The model proposes within a box you’ve drawn; the box is what makes the behavior repeatable.

In financial workflows this is non-negotiable. A number that renders differently on two identical runs isn’t a quirk, it’s a defect. So I push everything that must be exact — calculations, formatting, thresholds — out of the model and into deterministic code, and let the model do the genuinely open-ended reasoning. Knowing which parts must never vary is half of designing the system.

Most agent projects treat evaluation as something you bolt on near the end, once the interesting building is done. That ordering is backwards, and it’s why so many demos never survive contact with real use.

Without a real evaluation harness, you’re tuning by vibes — a prompt tweak feels better, so you ship it, with no idea what it broke. An agent that improves on the cases you happened to try can silently regress on the ones you didn’t. You can’t improve what you can’t measure, and impressions aren’t measurement.

I now build the eval set before the agent, not after. A modest suite of realistic cases with clear pass criteria turns development from guesswork into engineering. It’s slower to start and far faster to finish, because every change gets scored against reality instead of intuition. The eval isn’t overhead around the product — for an agent, it largely is the product.

A single model call is fairly reliable. Chain twenty of them into an autonomous loop and reliability doesn’t add — it multiplies. Each step that’s 97% reliable sounds fine until you compound it: twenty of them in a row lands you around 54%.

This is the arithmetic that quietly kills ambitious agent designs. The instinct is to give the agent more autonomy and more steps to handle complexity, but each step is another place for a small error to enter and propagate. Longer chains don’t just cost latency and tokens — they compound the probability of drift.

The design lesson is to treat steps as expensive even when they’re cheap to run. Collapse what can be collapsed, checkpoint state between phases so a failure doesn’t poison everything downstream, and prefer a few well-verified moves over many speculative ones. In agent systems, the shortest correct path beats the cleverest long one almost every time.

Teams debating which model to use are often optimizing the wrong variable. Once you’re past a capability threshold, the gap between good models is smaller than the gap between good and bad tool design around them.

A powerful model handed vague, overlapping, poorly documented tools will flounder. A modest model given clean, well-named tools with clear inputs and honest error messages will run circles around it. The tools are the interface between reasoning and action, and a bad interface caps how well any model can perform.

So I spend my design time on the tool layer: narrow responsibilities, predictable behavior, error messages written for a confused reader rather than a stack trace. The model is a given I don’t control; the tools are the part I do. Most of the reliability I’ve ever gotten out of an agent came from making its tools boring and legible, not from upgrading the brain behind them.

It’s tempting to describe a retrieval-augmented system as having memory. It looks the part — ask a question, and relevant facts appear in context. But retrieval and memory are different mechanisms, and conflating them leads to systems that fail in confusing ways.

Retrieval fetches whatever the query happens to match, with no sense of what the agent has already learned, decided, or committed to. It has no continuity. Real memory is stateful: it accumulates, updates, and privileges what mattered before. A retrieval system will happily surface a fact it contradicted three steps ago, because it isn’t remembering anything — it’s searching, every time, from scratch.

When I design agent systems, I keep the two layers distinct. Retrieval handles breadth: pulling relevant knowledge from a large corpus on demand. A separate, deliberately managed state layer handles continuity: what this run has established and must stay consistent with. Blur them together and the agent becomes fluent and forgetful at the same time — confident, well-sourced, and quietly incoherent.

Investing frameworks come and go with the cycle. Growth works until it doesn’t; value languishes until it doesn’t; momentum is brilliant right up until the reversal. The one idea that keeps earning its keep across regimes is the oldest one: buy meaningfully below your estimate of worth.

Margin of safety isn’t a strategy so much as an admission — that your estimate is probably wrong, and the gap between price and value is what protects you when it is. It converts analytical humility into downside protection. The wider the gap, the more the world is allowed to surprise you without ruining the outcome.

Every model I build ends with the same question, whatever the asset: how wrong can I be and still be fine? If the answer is not very, I pass, no matter how compelling the story. Precision is satisfying, but survival comes from the discount, not the decimal places.

The cash conversion cycle measures how many days a company’s cash is tied up between paying for inputs and collecting on sales. It’s a single number, and it quietly captures the operational health that ratios like margin tend to flatter.

A shrinking cycle means the business is getting more efficient at turning effort into cash — often a leading indicator of operational discipline before it shows up anywhere else. A stretching cycle, even alongside rising revenue, is a warning that growth is being funded internally in ways that won’t scale.

What I like about the metric is that it’s hard to game. You can massage reported earnings, but the physical reality of inventory sitting and receivables aging is stubborn. Watching the cycle over several quarters tells you whether a company is actually running tighter or just reporting that it is.

Consolidated financials blend everything into one story, which is convenient for a headline and misleading for analysis. A company is rarely one business — it’s a portfolio, and the portfolio’s average hides the parts that matter.

Segment disclosures are where the blend comes apart. One division may be a high-margin compounder quietly subsidizing a declining legacy unit that drags the consolidated multiple down. The market prices the average; the opportunity is in seeing the components the average conceals.

When I dig into a company, the segment footnote is the first place I go after the cash flow statement. It’s where you find the business that deserves a premium trapped inside a company the market treats as ordinary. Sum-of-the-parts analysis isn’t a gimmick — it’s just refusing to accept the consolidated average as the truth.

Goodwill is what a company paid for an acquisition above the fair value of the assets it received. Accounting treats it as an asset, but it’s really a frozen record of a bet — management’s conviction that the acquired business was worth more than its parts.

That makes the goodwill line unusually revealing. A balance sheet where goodwill dwarfs tangible assets is telling you the company’s value rests on integrations working out as promised. When they don’t, the impairment charge arrives — a public admission, in accrual form, that the price was wrong.

I read goodwill and its impairment history as a track record of capital allocation. Serial acquirers who never write anything down are either exceptional operators or optimistic accountants, and the difference matters. The line item nobody discusses at dinner is often the clearest window into whether management has actually created value or just moved it around.

A single-point valuation is a story with the uncertainty edited out. It says the business is worth $47 a share, as if the analyst has resolved every assumption. Nobody believes that, including the analyst, but the format pretends otherwise.

The sensitivity table is where the model stops performing confidence and starts telling the truth. It shows how the answer moves as growth, margin, and discount rate flex across plausible ranges. A thesis that only survives in one corner of the grid isn’t a thesis — it’s a hope with a spreadsheet attached.

I’ve come to read the table before the base case. If the value is stable across a wide band of reasonable inputs, the idea is robust and the point estimate is almost beside the point. If it’s knife-edge sensitive to a single cell, that cell is the whole investment, and it deserves far more scrutiny than the polished output ever gets.

The income statement tells you whether a company made money. The debt schedule tells you whether it will be allowed to keep operating the way it does. For distressed or leveraged businesses, the second question is the one that actually decides outcomes.

Maturities, covenants, and cash sweeps are where the real constraints live. A profitable company with a wall of debt maturing into a tight credit market is in more danger than a breakeven company with a clean runway. None of that is visible in EPS — it’s in the footnotes and the amortization table.

Building the debt schedule by hand is tedious, which is exactly why it’s valuable. Working through the mandatory paydowns and the covenant headroom forces you to see the year the model breaks. More than once, that exercise has changed a thesis from attractive to untouchable, on numbers the summary metrics never surfaced.

Precedent transaction analysis is seductive because it’s grounded in reality: these are prices real buyers actually paid. But that realism hides a bias. Deals that close are not a random sample of deals that were contemplated.

Every multiple in a precedent set carries a control premium and, often, a strategic buyer’s synergy assumptions baked into the price. Applying those multiples to a minority stake or a standalone valuation quietly imports someone else’s synergies as if they were yours. The comparable looks clean; the assumption underneath it isn’t.

I use precedent transactions as a ceiling, not an anchor. They tell me what the most motivated buyer paid under the most favorable narrative — useful context, but the wrong number to build a base case on. The interesting work is stripping the premium back out to see what the asset is worth to someone who doesn’t already believe the story.

Free cash flow is rightly prized because it’s harder to fake than earnings. You can defer expenses and pull revenue forward on the income statement, but the cash line eventually tells on you. That’s why cash-based investors sleep better.

But free cash flow has its own blind spots. A company can generate beautiful cash by underinvesting — starving maintenance capex, letting the asset base decay, harvesting a business it should be renewing. For a few years the cash looks pristine. The decline arrives later, off-model.

So I read the two statements against each other rather than picking a favorite. Earnings that consistently exceed cash flow is a red flag; cash flow that consistently exceeds earnings deserves a question about whether the company is investing enough to survive. The signal isn’t in either number alone — it’s in the gap between them and why it’s there.

WACC looks like a precise number. It has decimals. It comes out of a formula. And that precision is exactly what makes it dangerous, because almost every input is an estimate wearing a lab coat.

The equity risk premium is a debated range, not a fact. Beta depends on the lookback window you happen to choose. The cost of debt assumes a capital structure that may not persist. Move any of these half a point and the terminal value swings by double digits. The formula is real; the confidence it projects is mostly borrowed.

This isn’t an argument against discounting — it’s an argument for humility about it. In the Orcen Capital valuation stack I treat the discount rate as a scenario variable, not a constant. If a thesis only works at an 8% WACC and falls apart at 9%, that fragility is the finding. The honest move is to show the range and let the sensitivity speak.

Analysts spend most of their time on the income statement, because that’s where growth lives. But a surprising amount of enterprise value is won or lost on the working capital line — the unglamorous gap between when a company pays its suppliers and when it collects from its customers.

A business growing revenue at 20% while its receivables grow at 35% is not the same business it appears to be. The growth is real, but it’s being funded by cash that leaves the door faster than it comes back. On a DCF, that shows up as a persistent drag on free cash flow that the earnings headline never mentions.

When I model a company, I watch the cash conversion cycle before I trust the margin. Improving terms with suppliers, tightening collections, and turning inventory faster can create more value than a full point of gross margin — and unlike margin, it usually costs nothing but discipline. Working capital is where operational quality either compounds or quietly bleeds out.

Every comparable companies analysis makes the same implicit claim: these businesses are similar enough that their market multiples should be in the same range. The methodology is mechanical — collect EV/EBITDA, EV/Revenue, P/E across a peer set, apply to the subject company. What’s non-mechanical is the judgment call embedded in that implicit claim.

Selecting the comparable set is the most consequential step in the analysis, and it’s entirely discretionary. An analyst who wants a higher valuation selects comps trading at higher multiples. An analyst who wants a lower one selects conservative comps. Neither is technically wrong. The selection criteria — geographic market, business model, growth profile, margin structure, customer type — can all be argued plausibly in either direction.

This is why I think of comps analysis as storytelling with numbers. The numbers are real. The story you’re telling about why these specific companies are the right reference points is a narrative choice that drives the output as much as the multiples themselves.

In the Orcen Capital system, the comps section pulls from a structured peer database and applies explicit selection criteria that are logged and version-controlled alongside the model. The criteria don’t remove the judgment — they make the judgment explicit, so it can be examined and challenged. A comp set selected with documented criteria is worth more than an undocumented one because you can identify exactly which assumption is driving the output and test whether it holds.

The output of comps analysis is a range, not a number. Treating it as a number — the average of the peer multiples applied precisely to the subject — is false precision. The real output is a distribution of plausible values conditional on the comp set being appropriate. That conditionality matters.

Comps tell you what the market is paying for similar businesses. They tell you nothing about whether the market is right.

There’s a version of AI system design that chases novelty — multi-model orchestration, dynamic tool selection, emergent agent collaboration, recursive self-improvement. These are interesting research directions. They’re also catastrophically unreliable when something real is at stake.

The most reliable AI systems I’ve built use boring architecture: a single model call with well-structured inputs, deterministic post-processing of the output, explicit state management in a database, and hard-coded policy enforcement at the action layer. No emergent behavior. No dynamic tool selection. No agent deciding which agent to call next.

Boring architecture is predictable. Predictable systems fail in predictable ways, which means you can design for the failure modes in advance. Novel architectures fail in novel ways — ways you didn’t anticipate because the system’s behavior emerges from the interaction of components rather than from the explicit logic you wrote.

In OpsFlow, every major architectural decision I made was in the direction of explicitness over elegance. The action proposals are structured JSON, not natural language. The policy enforcement is if-else logic, not another model call. The state is stored in SQLite rows, not inferred from conversation history. Each of these choices sacrifices some flexibility for a significant gain in predictability.

The counterargument is that boring architecture limits capability. This is sometimes true. But capability is only valuable if the system behaves correctly when capability is exercised. A system that can theoretically handle any workflow but fails unpredictably is less useful than one that handles a narrower set of workflows reliably.

The most impressive AI demos use the most sophisticated architecture. The most useful AI systems use the simplest architecture that gets the job done. These are almost never the same thing.

The Orcen Capital valuation system outputs institutional-grade research. Eighty-four Excel sheets, a Word report, a sixteen-slide deck. The kind of deliverable that would cost tens of thousands of dollars from a boutique advisory firm.

I don’t manage a fund. I don’t have a portfolio to run the analysis against. In the most literal sense, I built a tool that produces outputs I have no immediate use for.

This is intentional.

The constraint of building for professional-grade output forces a level of rigor that building for personal use doesn’t. When the target is “good enough for me to understand,” the bar is low and easy to meet. When the target is “good enough that a professional analyst would trust this output to make a real decision,” you can’t cut corners. Every formula has to be right. Every output has to reconcile. Every assumption has to be defensible.

Building to professional standards without professional oversight is also the fastest way to find out where your understanding is incomplete. I can convince myself I understand a DCF by building one that produces a number. I can’t convince myself when the terminal value calculation has to survive scrutiny from someone who does this for a living. The gap between what I think I understand and what I can actually build correctly is exactly where the learning is.

There’s also a longer-term logic. The tools I build now, to standards I can’t fully use now, are the tools I’ll be reaching for when I have the access and the capital to use them properly. The work is an investment in the version of me that exists in a few years, not just the version that exists today.

Building things you can’t fully use is how you prepare for the moment you can.

Quality of earnings analysis sounds like accounting. It’s actually forensics.

The goal isn’t to verify that the financial statements comply with GAAP — the auditors handle that. The goal is to identify the gap between reported earnings and the cash-generative reality of the business, and to understand whether that gap is structural or temporary, disclosed or obscured.

The most common patterns the analysis surfaces aren’t fraud. They’re aggressive but technically permissible accounting choices that systematically flatter reported results: revenue recognized at contract signing rather than delivery, costs capitalized rather than expensed, warranty reserves set at the low end of the defensible range, restructuring charges that recur with suspicious regularity. None of these are illegal. All of them create a wedge between what the income statement says and what the business is actually generating.

The 84-sheet valuation model I built for Orcen Capital includes a dedicated quality of earnings section that flags these patterns explicitly. The inputs are the same public filings everyone else has access to — but the analysis compares revenue recognition timing to cash collection timing, tracks the accruals ratio over multiple periods, and flags any instance where reported income consistently outpaces operating cash flow. The flags don’t prove a problem. They direct attention to where the assumptions in the model deserve extra scrutiny.

What quality of earnings analysis catches, more than anything else, is the pattern of choices. A single aggressive accounting decision is noise. A consistent pattern of aggressive choices in the same direction, applied across multiple line items over multiple periods, is signal.

The numbers are rarely wrong. The choices that produce them sometimes are.

For most of financial history, information was the edge. If you had the earnings data before it was public, you had an advantage. If you had access to the terminal and the analyst knew how to use it, you had an advantage. The information asymmetry was real and durable.

That edge has largely disappeared. SEC EDGAR puts every filing online within hours. Earnings calls are transcribed in minutes. Alternative data that was exotic ten years ago is now a commodity product sold to hundreds of funds. The information is available. The question is what you do with it.

This is what drove the design of the Health Scanner. The eleven models it runs — Altman, Beneish, Piotroski, Dechow, and seven more — are all published in academic literature. The data they consume is public. The edge isn’t proprietary information. It’s systematic application at a scale that isn’t practical manually, combined with an interpretive framework for understanding what the signals mean in context.

The same dynamic applies to equity research more broadly. The earnings transcript is public. The 10-K is public. The options market data is public. What isn’t uniformly distributed is the analytical framework for deciding which signals to weight, in what combination, under what market conditions. That’s where the remaining edge lives — not in having different inputs but in having a better model of what the inputs mean.

This has a practical implication for how to develop as an analyst. Learning to access data matters less than learning to interpret it. The former is a skill that gets commoditized; the latter is a skill that compounds. The analyst who understands why Altman Z-Score produces false positives in capital-intensive industries will always do better than one who runs the model without understanding its assumptions.

The information is available to everyone. The interpretation isn’t.

One of the underappreciated design decisions in agentic AI is the stopping condition — the set of circumstances under which the agent should pause and request human input rather than proceeding autonomously. Getting this wrong in either direction is expensive: an agent that stops too often is just a chatbot with extra steps; one that stops too rarely is a liability.

The naive approach is to define stopping conditions by action type: the agent always asks before making a payment, always asks before sending external communications, always asks before modifying shared data. This is safe but blunt. It treats all payments as equivalent, all communications as equivalent. A $50 invoice and a $500,000 wire transfer trigger the same review process.

A better model parameterizes the stopping condition by risk, not by action type. The relevant variables are reversibility (can this be undone?), magnitude (how large are the potential consequences?), novelty (has the system handled this exact situation before?), and confidence (how certain is the model about its interpretation of the request?). High scores on any of these dimensions push toward human review; low scores on all four allow autonomous execution.

In OpsFlow, the authority matrix encodes this logic. Routine vendor payments within approved ranges and to verified vendors execute autonomously. Payments to new vendors, amounts above threshold, or any action flagged as novel by the system goes to a human approval queue. The agent doesn’t stop on a fixed schedule — it stops when the risk profile of the action warrants it.

The deeper design principle is that human oversight should be proportional to uncertainty, not proportional to action category. The value of autonomy is that it handles the predictable efficiently. The value of human review is that it catches the unpredictable before it becomes a problem. Designing the handoff between the two is where most of the real engineering work in agentic systems lives.

The goal isn’t to minimize interruptions. It’s to interrupt only when the interruption is worth more than the cost of the delay.

Most people encounter LBO analysis as a valuation tool — a way to determine what a private equity firm would pay for a business. This is a reasonable description of the mechanics but a slightly misleading description of what the model is actually doing.

An LBO model doesn’t ask “what is this business worth?” It asks: “at what entry price and capital structure can this business generate acceptable returns to equity holders, given plausible operating assumptions?” The distinction matters because the model works backward from a required return — typically 20-25% IRR — rather than forward from a theoretical intrinsic value.

What this means is that LBO analysis is structurally conservative. The leverage constraint disciplines the entry price. A business that requires $500M in debt to be acquired at a given valuation is constrained by whether its cash flows can service that debt through a downturn. The model is essentially asking whether the business is robust enough to survive the stress that comes with the capital structure needed to make the acquisition work.

In the Orcen Capital system, LBO analysis sits alongside DCF, comparable companies, and precedent transactions as one of four valuation anchors. What I’ve found is that the LBO floor is often the most useful data point — not because it gives the right price, but because it surfaces how much the business’s cash flow characteristics constrain what any financial buyer could rationally pay. When the LBO-implied value is significantly below the public market price, the business is either genuinely exceptional or the market is pricing in an assumption that financial buyers can’t make work.

The blended valuation output averages across methods, but the divergences between them are where the real information sits. A business trading at a 40% premium to its LBO value is a business where the public market is pricing in something that the debt markets aren’t willing to finance.

LBO models are best understood as a discipline, not a formula. They ask whether the business can support its own acquisition — a useful question even for investors who have no intention of buying the whole thing.

There’s an informal test that experienced recruiters apply to candidates before the first interview. It’s not about GPA or prestige. It’s about specificity.

A resume that says “developed financial models” is generic. One that says “built a DCF with 84 output sheets, 5 valuation methods, and 7 behavioral bias-correction modules” is specific. The specificity signals something important: the person either did the work or invented the detail. Both are more interesting than the vague claim.

The same test applies to how you describe outcomes. “Improved process efficiency” is generic. “Redesigned the client-onboarding system, reducing the time from first contact to signed contract by 35%” is specific. The number might not be exactly right. But it forces the candidate to have actually thought about what they measured and why the improvement mattered.

I learned this by noticing which of my own project descriptions felt hollow when I read them back. The ones that felt hollow were the ones where I hadn’t fully articulated what I built, why it was hard, and what it proved. The ones that felt solid were the ones where I could trace a direct line from the technical decision to the business outcome.

Specificity is hard to fake because it requires understanding. You can vaguely describe something you half-understand. You can’t be specific about it. That’s exactly why recruiters use it as a filter — not consciously, but by noticing when descriptions feel like they could have been written by someone who wasn’t there.

The work is the credential. But the work only counts if you can describe it precisely enough that someone who wasn’t there understands exactly what you did and why it was hard.

Most agentic AI failures are state failures. Not reasoning failures, not capability failures — failures to correctly track what has happened, what is currently true, and what commitments have been made across a multi-step workflow.

In a single-turn interaction, state is trivial. The user sends a message, the model responds, the interaction ends. Nothing carries over. In an agentic system that spans multiple steps, possibly across time, possibly across multiple model calls, state becomes the central engineering problem. What did the agent agree to? What actions has it already taken? What is it still waiting for? What should it do if a prior step is invalidated?

The naive implementation treats each model call as independent — passing the full context window and letting the model reconstruct its understanding of where things stand. This works until the context grows large enough that relevant information gets diluted, or until the model makes an inconsistent assumption about a prior action. In production, both happen regularly.

Building OpsFlow forced me to treat state as a first-class concern. Every action the agent proposes is logged to an SQLite ledger before execution. Every approval is recorded with its authority level and timestamp. Every pending item has an explicit status. The model doesn’t need to reconstruct state from the conversation history — it reads from a structured record that was written deterministically. What the model said it would do and what the system recorded it as doing are two separate things, and the system’s record is authoritative.

The practical benefit is auditability. But the design benefit is more important: when state lives in the database rather than in the model’s context window, the system doesn’t fail when the context gets long, doesn’t forget commitments made three steps ago, and doesn’t make inconsistent assumptions about what has already happened.

State management is boring infrastructure. It’s also the difference between a demo and a system that works in production.

Every quarter, management teams tell analysts what to expect. Revenue guidance, margin outlook, capex plans. Analysts update their models. The stock moves. And yet, academic research consistently shows that management guidance is systematically optimistic — and that the market consistently underweights this bias when pricing it in.

The mechanics are straightforward. Management teams have every incentive to set achievable targets — beating guidance drives short-term stock appreciation, and analysts who model miss rates into their price targets get deprioritized in investor calls. The result is a game where guidance is anchored just below what management believes is achievable, and where consecutive beats are treated as evidence of conservative management rather than as evidence that guidance is structurally low-balled.

One of the modules in the Orcen Capital system addresses this directly. The Behavioral Fingerprint tracks historical guidance accuracy for each management team — the gap between what they said and what they delivered, across quarters and across metrics. It computes a Trust Coefficient that discounts forward revenue and margin assumptions by management’s historical optimism rate. A team that consistently guides 200 basis points below actual margins has its forward margin assumptions reduced accordingly before they enter the DCF.

What this surfaces is that management quality varies dramatically as a forecasting signal. Some teams guide conservatively and beat consistently — their guidance is actionable information. Others guide aggressively and miss, or guide conservatively only when they lack conviction. The Trust Coefficient separates these behaviors in a way that qualitative analyst commentary rarely does.

The deeper issue is what guidance actually communicates. It’s not a forecast of what will happen. It’s a social contract about what management is willing to be held accountable for. That contract is priced very differently depending on who’s making it — and ignoring that difference is one of the more expensive mistakes in fundamental investing.

The market prices the number. The analysis should price the credibility of the person giving it.

Most things marketed as AI systems are actually AI tools. The distinction matters more than people realize, and it determines whether what you’ve built is genuinely useful or just impressive in a demo.

A tool does something when you ask it to. You provide input, it produces output. A chatbot is a tool. A summarizer is a tool. A code autocomplete is a tool. There’s nothing wrong with tools — they’re enormously valuable. But they require a human to initiate every action, interpret every output, and decide what to do next.

A system has state. It monitors conditions. It makes decisions about when to act without being asked. And crucially, it connects outputs to consequences — something happens in the world as a result of what it does.

When I built OpsFlow, the first version was a tool. You sent it a request, it processed the request, it returned a result. Useful, but fundamentally passive. The shift to a system happened when I added the trigger layer — the component that monitors conditions and initiates actions independently. When a vendor payment crosses a threshold, the system doesn’t wait to be asked. It flags it, requests approval, and routes it through the correct authority chain. The human’s job changes from doing to reviewing.

This distinction reshapes the design problem entirely. A tool fails when it produces a bad output. A system fails when it takes a bad action. The failure modes are categorically different in severity, which is why system design requires things that tool design doesn’t — state management, rollback capability, audit trails, and hard boundaries on what the system can do autonomously.

Most AI demos are tools pretending to be systems. They show an LLM completing a multi-step workflow — reading input, deciding a plan, executing steps, producing a result — and call it agentic. What they don’t show is what happens when the plan is wrong, when the context window loses track of a prior step, or when the execution environment changes mid-run. A genuine system has answers to those questions built into its architecture. A demo doesn’t need to.

Building systems rather than tools is harder. It requires thinking about failure before you experience it, which goes against the natural instinct to get something working first and harden it later. But the moment you connect an AI to real consequences — real money, real communications, real decisions — you’re building a system whether you planned to or not. Better to design it that way from the start.

In most DCF models, terminal value accounts for 60 to 80 percent of the total enterprise value. Which means most of what you’re doing when you build a DCF isn’t forecasting — it’s making a very precise-looking assumption about a number that depends entirely on what happens in perpetuity.

The standard approach is the Gordon Growth Model: take the final year’s free cash flow, assume a terminal growth rate slightly below long-run GDP, apply a discount rate, and divide. The formula is clean. The inputs are almost entirely discretionary. A one-percentage-point change in the terminal growth rate on a company growing at ten percent can move the output by thirty percent. The model doesn’t tell you that. It just gives you a number.

Building the valuation system for Orcen Capital forced me to think carefully about this. When the same pipeline runs dozens of companies, any error in the terminal value logic compounds across the entire output set. You can’t hide behind one company’s story — the pattern becomes visible.

What I built instead was a blended approach: the Gordon Growth Model anchors the estimate, but it’s cross-checked against an exit multiple derived from comparable transactions and a reinvestment-rate-adjusted growth estimate. If the three outputs diverge significantly, that divergence is flagged rather than averaged away. The model surfaces disagreement instead of resolving it into a false consensus.

The deeper issue is what terminal growth rates actually assume. Most analysts plug in a number between one and three percent and label it “long-run GDP growth.” What they’re implicitly assuming is that the company, in perpetuity, grows at the rate of the economy it operates in — no faster, no slower. For most companies, that’s probably the right central estimate. But for companies with durable competitive advantages, it understates value. For companies in structurally declining industries, it overstates it. The same input means something different depending on the business.

The most honest thing a DCF can do is make its sensitivity to terminal value explicit. Not a single number, but a range — and a clear statement of how much the output moves as the terminal assumptions change. The model doesn’t know the future. The value of building it carefully is that it tells you exactly where your uncertainty lives.

Most analysts present DCF outputs as if the model produced them. In reality, the analyst produced them and the model formatted them. The difference matters when you’re deciding how much to trust the result.

Most of what I’ve built has been solo. One person, one codebase, every decision mine to make and mine to live with. In the technology world, this is often framed as a limitation — real systems require teams, collaboration, code review, specialized roles. And that’s true, at scale.

But there’s something that happens when you build alone that doesn’t happen in teams: you can’t hand off the parts you don’t understand. Every piece of a solo project has to make sense to the same person. The architecture, the data model, the UI, the deployment, the edge cases — you can’t delegate any of it to someone else’s expertise. You either figure it out or the project stops.

This forces a kind of understanding that’s different from what you get reading documentation or following tutorials. When I built the valuation pipeline for Orcen Capital, I had to understand why each of the eleven financial models works the way it does — not just how to implement them. Because when two models disagreed on the same company, I needed to know which one to trust in which context. There was no senior analyst to ask.

Solo building also changes your relationship with failure. In a team, a broken feature is a shared problem with distributed ownership. Solo, a broken feature is yours. That accountability sounds punishing, but it’s clarifying. You learn exactly what you got wrong because you have to fix it yourself, and you remember the fix because you earned it.

The constraint I’ve found most valuable isn’t the technical depth it forces — it’s the product thinking. When you’re building alone, there are no internal customers to blame for bad requirements. If you build the wrong thing, you built the wrong thing. That keeps you honest about what actually matters versus what’s interesting to build.

I’ll work in teams. The best systems are built by groups of people who each understand their domain deeply and communicate well across domains. But building alone first — really alone, with no one to fill the gaps — is one of the better ways I know to find out what you actually understand versus what you thought you understood. The gap between those two things is usually where the real learning is.

Equity analysts set price targets by forecasting cash flows. Options markets set prices by forecasting distributions. The difference is not semantic — it reflects fundamentally different information about the same company, and the options market is often earlier.

A standard equity price target is a point estimate. The analyst says: in twelve months, given my revenue and margin assumptions, the stock should be worth X. That single number embeds a forecast and a confidence level — but the confidence level is invisible. Two analysts can have the same price target with radically different uncertainty about how they get there.

Options pricing makes uncertainty explicit. The implied volatility surface — the volatility that makes observed option prices consistent with the Black-Scholes formula — encodes the market’s collective expectation of how much the stock can move, at what probability, over what time horizon. The put-call skew tells you whether the market is more worried about downside than it is excited about upside. These aren’t opinions. They’re prices, backed by capital.

One of the modules in the Orcen Capital system is an options probability engine that derives scenario probabilities directly from the options market rather than using static analyst-assigned weights. The standard approach is to assign 30% probability to a bear case, 50% to base, 20% to bull, and average. Those weights are invented. The options-derived weights are observed — they reflect what the market is actually paying to be protected against specific outcomes.

The divergences between equity consensus and options-implied probabilities are where the most interesting analysis lives. When an analyst has a buy rating with a twelve-month target implying thirty percent upside, but the options market is pricing a put-call skew suggesting significant downside protection demand — those two things can’t both be right. One of them is missing information the other has. Usually it’s the analyst.

This doesn’t mean the options market is always correct. Options prices can be distorted by hedging demand, liquidity constraints, and positioning dynamics that have nothing to do with fundamental value. But they’re forward-looking by construction, updated in real time, and priced by participants who have money at risk. That combination gives them information content that backward-looking financial models frequently miss.

The most useful skill in equity research might be learning to read both signals simultaneously — understanding what the income statement says the company is worth, and understanding what the options market says could go wrong. The gap between them is where the real risk lives.

Financial analysts have a debugging practice they don’t call debugging. They call it reconciliation. You take a number that doesn’t match what you expected, and you work backward systematically until you find where the discrepancy entered. You don’t guess. You trace.

I learned this doing financial modeling before I learned to code seriously, and it turns out to be a better mental model for debugging software than most of what gets taught in programming contexts.

The standard debugging instinct for someone new to coding is hypothesis-driven in the wrong direction: form a theory about what might be wrong and check if it’s right. The problem is that your theories are constrained by what you already know, and bugs live in exactly the places where your mental model of the code is incorrect. You keep checking the things you think are wrong, which aren’t, while the actual problem sits in the thing you assumed was fine.

Reconciliation works differently. You identify two points — where the data enters and where the output is wrong — and you narrow the distance between them systematically. You don’t start with theories. You start with the discrepancy and follow it backward. Each step eliminates a section of the system. Eventually you isolate the exact location where the error enters. Then you understand what happened and why.

When the Health Scanner started producing anomalous scores for certain companies, my first instinct was to check the formula implementations — the obvious place, the place I might have made a mistake. The reconciliation approach said: check what the raw data looks like at ingestion, check what it looks like after cleaning, check what it looks like before it enters the model. The error was in the XBRL parser handling a specific tag format that certain filers used differently. I would have checked the formulas for hours and never found it.

The deeper lesson is about what it means to understand a system. In finance, you know you understand a model when you can reconcile any output back to its inputs without gaps. In software, the equivalent is being able to trace any unexpected output back through the code to the point where the invariant broke. Both require the same thing: a complete enough mental model that there’s nowhere for an error to hide.

Most debugging is slow because the mental model has gaps. Building better mental models — not faster hypothesis-testing — is what makes debugging fast. Finance taught me that before code did.

Prompt engineering treats LLMs as black boxes with a specific input format that produces better or worse outputs depending on how you phrase the request. There’s truth in this. Phrasing matters. Structure matters. Context matters. But framing the entire practice around “engineering the prompt” leads to the wrong intuitions about what’s actually happening.

The more accurate mental model is information architecture. You’re not manipulating a function with magic words. You’re giving a reasoning system the information it needs to do what you want, structured in a way that makes the right reasoning path easier to follow than the wrong one. The craft isn’t in the phrasing — it’s in the design of what information to include, in what order, with what level of specificity.

This reframe changes what you optimize for. Prompt engineers optimize for phrases and templates. Information architects optimize for completeness and structure. When a model produces a bad output, a prompt engineer tries different wording. An information architect asks: what information was missing, what information was ambiguous, and what in the structure made the wrong interpretation easier than the right one?

Building the narrative bridge module for Orcen Capital — the component that converts qualitative text into structured DCF parameter shocks — required solving this problem at scale. The same earnings call transcript produced wildly different parameter outputs depending on how I structured the information passed to the model. The turning point wasn’t finding better phrasing. It was building a preprocessing layer that extracted specific claim types — guidance revisions, margin commentary, demand signals — and presented them in a standardized structure before the model ever saw them. The model’s job became easier because the information it received was better organized, not because the instructions changed.

The prompt engineering framing also encourages fragility. A carefully tuned prompt that works for one model version, one temperature setting, one use case is brittle. An architecture that gives the model well-organized information and clear reasoning objectives tends to generalize. You’re working with the model’s capabilities rather than around its limitations.

The most useful skill in working with LLMs isn’t knowing what words to use. It’s knowing what information a reasoning system needs to do good work, and how to present it clearly. That skill transfers across models, versions, and use cases. The prompt tricks don’t.

In 1996, Richard Sloan published a paper showing that companies with high accruals — where reported earnings exceed actual cash generated — consistently underperformed the market in the following year. The effect was large, persistent, and largely ignored by the companies reporting those numbers. He called it the accruals anomaly. Nearly three decades later, it’s still one of the most robust signals in empirical finance.

The mechanism is straightforward. Accrual accounting lets companies recognize revenue before cash arrives and defer expenses into future periods. Done legitimately, this smooths out lumpy business cycles and gives a cleaner picture of economic performance. Done aggressively, it creates a gap between what the income statement says and what actually landed in the bank account. The market, Sloan found, tends to price the reported number and only corrects when cash flows eventually reveal the discrepancy.

What makes the anomaly interesting from a screening perspective is how early it shows up. In the companies I’ve run through the Health Scanner, the accruals ratio starts deteriorating before the solvency models catch anything meaningful. A company’s Altman Z-Score might still sit comfortably in the safe zone while its accruals-to-assets ratio has been widening for two or three years. By the time Z-Score flags distress, the accruals problem is usually severe — and anyone watching the stock price has already seen the correction.

The Dechow F-Score, one of the eleven models in my screening tool, is built almost entirely around this insight. It measures the probability of earnings manipulation using accruals-based inputs: the ratio of non-cash working capital to revenue, changes in cash sales versus reported sales, and the gap between reported earnings and operating cash flow. A high F-Score doesn’t prove fraud — it identifies companies where the accounting is stretched in ways that historically precede restatements and stock price collapses.

Running this cross-sectionally across 600 companies at once changes the interpretive challenge. A single high accruals ratio in isolation could be legitimate — a company that just signed a large contract and recognized upfront revenue with deferred cash collection. But a company with high accruals AND a deteriorating Piotroski F-Score AND weakening Beneish signals is telling a different story. The convergence of signals across independent models is where the real information sits.

The counterintuitive implication is that the most dangerous companies to own are often the ones that look fine. Strong reported earnings, reasonable leverage, growing revenue — but cash flow from operations quietly underperforming net income for four consecutive quarters. The headline numbers pass every basic screen. The accruals ratio doesn’t.

Sloan’s 1996 finding has been replicated across markets, time periods, and asset classes. The anomaly persists not because the market doesn’t know about it — it’s been published, taught, and traded for thirty years — but because most investors still anchor on reported earnings. That anchor is expensive.

Everyone building agentic AI right now is making the same mistake: they’re letting the model decide and act at the same time.

In demos, this looks impressive. The model reads a prompt, plans a sequence of steps, calls some tools, and produces an output. It feels autonomous. It feels like the future.

In production, it’s a liability.

I found this out building OpsFlow — an AI operations agent that handles vendor payments, approvals, and workflow routing. The first version did what most agentic systems do: the LLM received a request, generated a plan, and executed it. Fast to build. Flexible. And completely unacceptable for anything involving money.

The problem isn’t that language models are bad at planning. They’re surprisingly good. The problem is that when they’re wrong — and they will be wrong — there’s no catch. One hallucination, one misread context window, one ambiguous instruction and the model sends a payment to the wrong address, routes an approval to the wrong person, or skips a required review step. By the time a human notices, the damage is done.

The fix isn’t to make the model smarter. It’s to change what the model is allowed to do.

The architecture I settled on separates reasoning from execution. The LLM receives a request and generates a proposed action plan — a structured list of steps with parameters. That proposal passes through a deterministic policy layer: hard-coded rules that validate each action against predefined constraints. Vendor in the approved list? Payment within the authorized range? Quorum threshold met for this approval tier? If any check fails, the action is blocked. The model can’t override it.

What executes is never what the model decided alone. It’s what the model proposed, filtered through rules that don’t hallucinate.

Think of it like the relationship between a junior analyst and a compliance department. The analyst can be creative, thorough, insightful. But the compliance rules exist precisely because individual judgment — even good judgment — isn’t sufficient for high-stakes decisions. The rules run independently of how confident the analyst sounds.

The secondary benefit is auditability. When every action passes through a deterministic layer before execution, you get a complete record of what was proposed, what was validated, what was rejected, and why. Not just logs of what the model said, but a verifiable trail of what the system actually did. In regulated environments, that trail isn’t optional.

The insight I keep coming back to: trustworthy agentic systems aren’t built by making models more reliable. They’re built by designing systems where model unreliability has bounded consequences. The model can be wrong. The system shouldn’t be.

I built a tool that screens 600+ public companies for financial distress using eleven academic models simultaneously. Running it has taught me more about financial analysis than any course I’ve taken.

The models — Altman Z-Score, Beneish M-Score, Piotroski F-Score, Dechow F-Score, and seven others — each look at the same company from a different angle. Altman asks whether the capital structure suggests insolvency within two years. Beneish asks whether the earnings have been manipulated. Piotroski asks whether the business is fundamentally improving or deteriorating. None of them, alone, tells you much. Together, they tell you almost everything.

The pattern I keep seeing in companies that score poorly across multiple models: the accruals gap opens first.

Accruals are the difference between reported earnings and actual cash generated. A company can report profit while burning cash if its accounting choices consistently favor recognizing revenue early or deferring expenses. For a quarter or two, this is manageable and sometimes legitimate. Over multiple years, a widening gap between net income and operating cash flow is almost always a warning sign — either the business model is deteriorating, or the accounting is being stretched.

What’s striking is that this signal appears before the other models catch it. A company’s Altman Z-Score might still look acceptable while its accruals ratio is already deteriorating. By the time the Z-Score flags distress, the accruals problem is usually severe and the stock has already moved.

Running the same screen across hundreds of companies simultaneously changes how you think about analysis. Individual company work is about depth. Cross-sectional work is about pattern recognition. When you can see all 600 companies ranked by accruals quality at once, outliers that would be invisible in isolation become obvious immediately.

The tool also surfaced something about sector interpretation: certain industries structurally produce companies with poor scores on specific models — not because the businesses are failing but because the accounting characteristics of the sector look like deterioration to a model calibrated on the broader market. Capital-intensive industrials often score poorly on asset turnover. Biotech companies in development phase look terrible on profitability metrics. The models are useful, but they require interpretation. Knowing when to trust the signal and when to adjust for sector structure is as important as running the models.

What I’ve taken from this: financial analysis is fundamentally a pattern recognition problem that happens to require deep domain knowledge to interpret correctly. The models don’t replace understanding the business. They systematically surface where the understanding is most needed.

There’s a conventional assumption in the AI space that the best builders come from computer science. Strong priors on system design, algorithms, and software architecture. For purely technical problems, this is probably right.

But most of the valuable AI to be built in the next decade isn’t purely technical. It’s operational. Workflow automation, decision support, financial analysis, risk assessment — problems that exist inside organizations with existing processes, compliance requirements, and human stakeholders. Problems where the hard part isn’t building the model. It’s understanding what the model is actually supposed to do.

This is where domain knowledge compounds technical skill rather than competing with it.

When I built OpsFlow, the interesting design decisions weren’t technical. They were operational. What counts as a valid vendor approval? What does a quorum requirement mean in an async workflow? What happens when a payment is initiated but the approval chain breaks halfway through? These questions don’t have clean answers in a CS curriculum. They have answers in the messy reality of how organizations actually make decisions and move money.

When I built the Health Scanner, the hard problems were interpretive. Which financial ratios matter in which industries? When does a high Beneish M-Score reflect genuine manipulation and when does it reflect legitimate sector accounting? The tool is Python. The judgment is finance.

My background creates a specific kind of advantage: I know what the workflows are actually trying to accomplish, so I can design systems that fit the workflow rather than systems the workflow has to accommodate. The user of an agentic system doesn’t think in API calls and state machines. They think in business logic. Building for them requires fluency in both.

Purely technical builders often produce systems that are sophisticated and brittle — technically impressive but operationally naive. A payment system that doesn’t model the approval hierarchy correctly isn’t a payment system. An AI document processor that doesn’t understand the compliance context of what it’s processing creates liability rather than efficiency.

In the class of problems where AI is going to create the most value — automating knowledge work inside complex organizations — the combination of domain depth and technical skill is more powerful than either alone. And that combination is rare enough, right now, to be a genuine edge.

To Whom It May Concern:

I am pleased to recommend Aleks Arriola, who worked with us as a Finance Intern at The 1525. During his time with our team, I had the opportunity to see firsthand how Aleks approaches complex assignments, works with others, and applies his analytical skills to real business challenges.

What impressed me most about Aleks was his ability to take ownership of his work. In a fast-moving company, assignments are not always presented with perfectly defined parameters or step-by-step instructions. Aleks was comfortable operating in that environment. He could take an objective, determine what information was needed, work through ambiguity, and deliver thoughtful, polished work without requiring constant supervision. As a founder, that level of reliability is something I value tremendously.

Aleks also demonstrated strong analytical ability and business judgment. He approached research and financial analysis with attention to detail, but he understood that analysis is only valuable if it helps a company make better decisions. Rather than simply presenting numbers or information, he worked to understand what the data meant, identify the most relevant insights, and connect his findings to practical business considerations. That ability to move between detailed analysis and the larger business picture will serve him particularly well in finance and other analytically demanding roles.

I was equally impressed by Aleks’s willingness to embrace technology as a problem-solving tool. He showed an understanding of how emerging tools, including AI, automation, and data-driven workflows, can be used to work more efficiently and improve the quality of an end product. More importantly, he did not approach technology simply for the sake of using technology. He looked for ways it could solve an actual problem, streamline a process, or improve a deliverable. That combination of analytical thinking and technological fluency is becoming increasingly valuable in today’s business environment.

Aleks was also an effective communicator and a strong member of our team. He was able to take complicated information and communicate it clearly, was receptive to constructive feedback, and consistently approached conversations professionally. When feedback was provided, he incorporated it into his work rather than becoming defensive about it. He demonstrated curiosity, maturity, and a genuine desire to improve throughout his internship.

Internships are intended to give young professionals an opportunity to learn, but the strongest interns also find ways to create meaningful value for the organizations they join. Aleks did both. He took his responsibilities seriously, earned our trust, and demonstrated many of the qualities I would look for when evaluating someone for a full-time professional role.

Based on my experience working with Aleks, I am confident that he will bring the same ownership, analytical rigor, curiosity, technological fluency, and professionalism to his next opportunity. I believe he has a very strong foundation for a successful career, and I am happy to recommend him without hesitation.

Sincerely,

Jason Sizer

Director, The 1525