From Microsoft infrastructure to AI trading research: what building Veyra is teaching me

By Palanikumar Annamalai · Kumar · 10 November 2026 · Approximately 14 minutes

The idea in one minute

The video is silent, with captions, and starts only when you press play. Canva supplies the original orb artwork, layout and exported motion; the final 60-second sequence combines that export with factual captions and an actual application screenshot. No music or synthetic voice is used.

Read the video transcript

0–8 seconds: It started with curiosity. Could AI help me turn an idea into software? Veyra is my independent learning project.

8–18 seconds: I have built software before: LISA, my FoxBASE accounting application. From Lunar Systems to Microsoft engineering; now I am learning through Veyra.

18–30 seconds: Coding agents, focused roles and local-model experiments need ownership. Claude, Codex, Cursor and Antigravity. ProPR coordinates development, not trading.

30–42 seconds: Hypothesis, rules, backtest, walk-forward and review. A passing build or attractive chart does not prove predictive performance.

42–52 seconds: Actual Veyra 0.3.0 interface, captured 10 November 2026. Demonstration view: no connected inference. Unavailable outputs are not trading results.

52–60 seconds: What would you improve? Markets move. Veyra thinks. Veyra acts. Project vision: autonomous execution is unfinished. Read the story at palanikumar.net.

It started with curiosity

Posts about AI and trading kept raising a question for me: could I build something that made the underlying reasoning inspectable? I wanted to understand what sits between an interesting idea, a model’s answer, a convincing chart and a decision that deserves trust.

That became Veyra. My background is Microsoft cloud, infrastructure, identity and security. I am bringing that experience into unfamiliar territory: AI-assisted software development and trading research. I am learning the research discipline as well as building the software. Those are different kinds of progress.

The project vision is “Markets move. Veyra thinks. Veyra acts.” It describes a direction. It does not mean autonomous execution is complete, or that Veyra has demonstrated an investment advantage.

What has encouraged me most is seeing an idea become something I can open, inspect and improve. AI has shortened the distance between a question and a working experiment. It has also made it easier to produce more software than I can responsibly understand without a deliberate review process.

I have built useful software before

This is not my first attempt to turn an idea into an application. At Lunar Systems, which I ran, I developed a FoxBASE accounting application called LISA. That work sat alongside building and repairing computers and helping people use them. I have described that earlier experience in my account of the progression from radio experiments to cloud security.

Accounting software and trading research are different problems. The connection is the habit of starting with a practical need, working through the data and finding out where the implementation disagrees with reality. A screen that looks complete does not guarantee the records behind it are correct.

Years of infrastructure work reinforced that habit. Identity has an authority. A service has dependencies. A failed operation may have partially changed state. A recovery needs verification. An automated task needs an owner, limits and a record of what happened.

Those questions transfer to Veyra. They do not make me an experienced quantitative researcher. They do give me a way to investigate an unfamiliar system without treating a confident explanation as a substitute for evidence.

How AI helps me turn an idea into software

I use Claude, Codex, Cursor and Antigravity across development, investigation, review and interface exploration. Their assignments have varied as the project has evolved; I do not treat a product name as a guarantee of a particular kind of expertise.

They help me turn a broad intention into smaller questions: what is the input contract, which component owns the state, what would a test need to demonstrate, and what should the interface show when evidence is missing? They can explain an unfamiliar library, propose code, examine a diff and help build a prototype I can inspect.

My responsibility remains to decide what problem I am solving, examine the evidence and reject work that does not meet the requirement. An agent can generate a plausible answer from incomplete context. Two agents can repeat the same assumption. A successful build proves that a particular build completed; it does not prove the strategy, data or execution path is correct.

The useful message I want to share is that AI can help an experienced engineer make an unfamiliar idea tangible. Curiosity supplies the question. Domain learning, verification and persistence determine whether the result becomes useful. Prompting is part of that process, alongside reading code, tracing failures and simplifying the design.

Multiple coding agents need boundaries

Parallel work initially sounds like an easy way to move faster. It creates its own failure modes: overlapping edits, stale assumptions, a reviewer inspecting an earlier commit and a passing check being attributed to a different version.

The practice I am learning is to give each task an owner, a bounded scope and an isolated branch or worktree. A handoff should identify the exact revision, files changed, tests actually run and unresolved limitations. Independent review should challenge the implementation rather than restate its author’s explanation.

I also separate coordination from execution. ProPR is development orchestration in this project: work intake, ownership, review and integration. It is not the trading engine, a market predictor or permission to send an order. A running development service does not establish that every planned development workflow has been activated or qualified.

This distinction has helped me make progress without turning every tool into another controller. More agents are useful only when their outputs can be reconciled into one understandable system.

How the pieces fit together

There are two paths to keep separate. Development tools change reviewed software. The research system consumes evidence and produces research records or proposals. Any future execution must pass the deterministic control boundary.

This is native, selectable HTML so the sequence and authority boundary remain accessible. The illustration below is conceptual artwork, rather than an exact component or deployment diagram.

Focused micro-bots, rather than one all-knowing model

I use “micro-bots” to describe focused research responsibilities. A text researcher, a feature scorer and a challenger should have different inputs and explicit outputs. Their usefulness depends on attributable evidence, not on the personality or animation attached to a card.

The dashboard currently exposes roles such as Pulse for text sentiment, Horizon for return and volatility research, and Compass for offline policy evaluation. It also distinguishes disabled, planned and proposed roles. At capture, the Intelligence Hub stated no connected inference. A role definition is not a running, qualified researcher.

An eventual evidence record needs the source, time, model or rule version, limitations and the reason for support, opposition or abstention. Several models agreeing on a story is weak reassurance if they share the same source, training biases or contaminated examples. Counting repeated reports of one event as independent evidence makes that problem worse.

Local models require more than a download

Hugging Face has helped me understand the difference between a library, a model repository and a particular set of weights. A library’s licence does not automatically cover the weights loaded through it. Before adopting a model, I need its model card, licence, intended use, limitations, revision and evaluation requirements.

For reproducibility, the aim is to pin the weight revision and supporting environment, record the input and compare the resulting artefact. Offline inference requires the relevant files to be available locally; it should not quietly download a different version during an experiment. Hugging Face documents both revision selection and local-only loading in its download API.

BGE embeddings are a candidate I want to evaluate for retrieval and near-duplicate detection. They map text into representations that can help retrieve related material. That could help identify repeated news descriptions before they are counted as distinct evidence. It does not determine whether a news claim is true or predict its market effect. The BAAI bge-small-en-v1.5 model card declares an MIT licence; other models need their own checks. I am not presenting a qualified BGE integration as completed here.

For numerical research, the inspected source contains separate XGBoost and LightGBM shadow-scoring modules. LightGBM reuses the XGBoost experiment’s example preparation and temporal evaluation contracts so a challenger cannot quietly benefit from a different comparison. Source presence is useful evidence of implementation; it is not evidence that a particular trained model adds value.

Forecasting approaches, including recurrent models and proposed forecast-comparison roles, need separate evaluation. A price forecast, a probability estimate, a retrieval score and a strategy decision are different outputs. They cannot sensibly be added together as if they shared one meaning. I want a simple reproducible baseline before adding another model family.

Strategy Lab: write the hypothesis before admiring the chart

My intended research sequence is hypothesis → explicit rules → backtest → walk-forward evaluation → qualification. Qualification can end in rejection, inconclusive evidence or unavailable data. None of those should be hidden to make the interface feel successful.

A hypothesis needs a universe, holding horizon, information availability rule and a comparison. A backtest needs a declared data snapshot, transaction costs and execution assumptions. Walk-forward evaluation needs time-ordered training and evaluation boundaries; overlapping labels may require additional separation. A generic split function does not solve all leakage problems. Scikit-learn’s TimeSeriesSplit documentation explains its time-ordering and gap controls, which are a starting point rather than a complete financial validation protocol.

The current Research Lab includes a local hypothesis notebook, experiment contracts and a workflow illustration. Its demo button does not run a real backtest or train a model. The interface says so. I want the eventual research experience to preserve that honesty when real producers are connected.

The experiments that taught me to distrust an attractive result

Some of the most valuable work has been finding reasons to reject a result. Historical research reviews identified timing and price-basis defects, inconsistent accounting between replay paths and repeated reuse of an evaluation window. I am treating those findings as reasons to withhold qualification, rather than publishing the earlier attractive figures.

A signal calculated from a closing price cannot simply assume it traded at that same close without a defensible execution model. Adjusted prices, raw prices, splits and distributions need consistent treatment. A dividend’s ex-date and the date cash becomes available are different events. Two engines disagreeing about a portfolio result need investigation before either number becomes a headline.

Another lesson is that a holdout stops being untouched once I inspect it and change the strategy in response. Repeatedly tuning against the same period does not become independent validation because each run has a new filename. Trial history matters, including abandoned variants and negative results.

Independent review also challenged descriptions that sounded more sophisticated than the code: a deterministic threshold rule should be described as that rule, not as a fitted probabilistic model. These are research and implementation lessons, not a claim that every identified defect has now been repaired.

Risk and recovery belong outside the language model

Infrastructure experience makes this boundary particularly important to me. Research can be probabilistic; authority and state changes need explicit rules.

Veyra’s architecture separates proposals from position management, deterministic risk checks, durable order management and the broker gateway. Protection and reconciliation are responsibilities of their own. A timeout after submission cannot safely mean “nothing happened, try again”. An unknown outcome needs reconciliation. An explanation that says a position is protected is not the same as an acknowledged protective order.

The inspected architecture requires research models to remain outside that authority boundary. Offline modules and tests do not establish a qualified connected execution lifecycle. I am not claiming that the complete native path is ready for unattended operation.

What the dashboard actually demonstrates

I inspected the published application rather than using an older local prototype. It showed Veyra 0.3.0 and an independent sandbox label. Market observations, local simulations, historical research artefacts and unavailable producer outputs need separate labels.

The overview crop below shows the decision-flow interface, including a quote count alongside unverified or inactive stages. A quote arriving does not demonstrate that the feature engine, model committee and execution chain ran on it. I have excluded account information and provider price charts from the published crops.

Where the project stands

These labels are deliberately scoped. “Tested” describes an observed check, not an endorsement of the entire system.

Status	What I can support today	What it does not establish
Implemented	Navigable research and intelligence views, explicit demonstration/unavailable states; separate ML shadow-scoring source and deterministic control architecture.	That every producer is connected, model trained or execution path qualified.
Tested	The published views were opened and their status labels inspected for this article. Historical research has been independently challenged against code and artefacts.	Fresh end-to-end trading acceptance, a new ML benchmark or correction of every historical finding.
Experimental	Strategy hypotheses, shadow model comparisons and historical research candidates, including rejected or inconclusive work.	Predictive value, profitability or suitability for someone else’s use.
Planned	Qualified local retrieval/deduplication, broader reproducible model comparisons and complete evidence-backed integration and recovery acceptance.	Permission to activate a model, purchase a feed or trade.

My next steps are to simplify the baseline, improve point-in-time data checks, preserve full trial ancestry and connect producers only when their provenance and limitations can be inspected. I want better failure evidence before I want more animated success states.

What I would like to learn from you

If you have worked on similar systems, I would value practical recommendations:

• Which reproducible strategy-research resources would you recommend—papers, repositories or benchmark protocols?
• What point-in-time data and corporate-action practices have worked for you?
• Which small local models have demonstrated useful incremental value against a simple baseline?
• How do you evaluate leakage, calibration and trading costs?
• What would you simplify in this architecture?
• What have you learned coordinating multiple coding agents?

Please share public resources and practical experience, rather than confidential material, investment recommendations or promises of profitable strategies.

Building Veyra has reminded me of the satisfaction of building LISA: an idea becomes useful through attention to how the system actually behaves. AI gives me more ways to attempt the work. I still have to ask the questions, examine the failures and keep improving it.

Independent-project disclosure: Veyra is my personal learning and research project. This article does not represent an employer or imply employer involvement or endorsement. It is an engineering retrospective, not investment advice or a product performance claim.