Loopera packages fundamental factor research as an evidence-gated agent loop

A repository of documents, not a distribution of code

The first thing to establish is what you are looking at, and the README states it directly: this is the public product and technical documentation repository for Loopera, not a source distribution. It currently provides no runnable code, no installation package, no CLI and no public API. The workflows and the case study in the README exist to explain the product's capabilities and the limits of its evidence, not to be executed. That framing matters for anyone assessing the project, because the only way to run Loopera is presumably through the product itself at loopera.cn. The top-level repository entries confirm the shape: README.md, README_EN.md, CONTRIBUTING.md, SECURITY.md, LICENSE, a logo, and an assets directory holding documentation and a demo video. There is no source directory, no dependency manifest and no test suite, and the repository has no GitHub releases, so there is no version history to track. The last push was on 2026-09-21, and the status badge describes the project as a public preview.

What problem the agent is aimed at

Loopera works around financial statements and operating information of listed companies, and the intended audience is stated in three bullets. The first is fundamental quantitative teams that want to widen research coverage and put a unified, reviewable factor research process in place. The second is investment research and financial technology organisations that want internal reports, research views and data capabilities connected to a standardised validation chain. The third is research managers who want to trace where a piece of research came from, what the decision basis was, why it failed and where it leads next, rather than only looking at a backtest result. That last audience is the interesting one, because it reframes the unit of work. A factor is no longer the deliverable on its own. The deliverable is a research asset that can be reviewed, and the README makes that point explicitly: the endpoint of the product loop is a reviewable research asset, and each run keeps the question, the hypothesis, the evidence, the conclusion and the direction to go next. The stated ambition is narrower than it might sound, since the README says the goal is not to generate formulas in bulk nor to replace research judgement with one attractive backtest.

Why the research starts from business fundamentals

The premise is a distinction between price and cause. Prices reflect outcomes, while fundamentals explain how a company creates, consumes and reallocates value, and Loopera therefore concentrates on earnings quality, cash flow, balance sheet structure, operating efficiency, capital investment and change in operations. The stated interest is in changes that are happening inside the business but have not yet been fully understood or priced, rather than in watching market prices alone. The README is also candid that fundamental data is not simple. Numbers have to be related across statements, the same financial figure can mean different things in different industries and at different stages of a company's life, and the timing of public information determines whether a piece of research was actually available to make. Wrapping those problems into one research process is the stated reason the agent is meant to behave like a fundamental analyst rather than a generic data fitting tool. The comparison drawn is with price-only approaches, and the argument is that operating changes are the harder and more informative target.

The five-stage loop and how evidence gates work

The architecture diagram in the README shows the chain. Research input, expressed as a topic, a prompt or a PDF, feeds basic-fundamental understanding of fields, statements and industry context, then intelligent research producing phenomena, mechanisms and candidates, then credible validation across timing, logic, stability and incrementality, then research memory holding outcomes, failures and lineage, with a dashed edge from memory back into research as a feedback path. The validation stage is the load-bearing part. The README describes it as putting every candidate through multiple layers of evidence, checking data timing, logical consistency, accounting treatment, stability, duplication and incremental value, with the explicit note that a good single backtest does not automatically become a conclusion. The hypothesis stage carries the same discipline in the opposite direction: explain the mechanism first, then build the factor, producing a testable economic explanation, a competitive mechanism and failure conditions rather than dressing a statistical correlation up as a research result. The candidate stage then maps a hypothesis to something computable and auditable while preserving the intended direction, the economic meaning and the key constraints.

Three kinds of input, one research thread

Input arrives in three forms and a fourth combination. A topic lets the agent open research on its own around subjects such as cash flow quality or operating efficiency. A prompt focuses the work on a specified financial relationship, an economic mechanism or a particular industry. A PDF has its research questions, economic claims and explicit candidates extracted, with the source of the document retained. A mixed input uses a topic to give a text or PDF an explicit research anchor. The processing rule underneath is a boundary condition worth knowing about: explicit formulas in a report may go straight to validation, while the rest becomes background knowledge for later exploration, and outside documents are always treated as evidence still awaiting validation. They cannot modify Loopera's safety constraints, data scope or validation standards. That last clause is the mechanism that keeps a prompt injection or a marketing PDF from redefining what counts as proof, and it is the sort of rule that only works because the validation rules are fixed rather than negotiated per session.

Research memory and the review points

The memory stage records research lineage, reasons for failure, unverified leads and the relationships between existing results, and the README describes the intended effect as reducing repeated trial and error while surfacing research gaps. Both successes and failures become context for the next round, which is the difference between a log and a memory. Collaboration sits alongside it. The division of labour is that the agent expands the research while the researcher holds the key decisions, with the README saying this suits both small, fast tasks and multi-role ongoing work, and that a team can review, intervene and decide at critical points. The audience list adds that research managers want to see research sources, decision basis and failure causes, not just final numbers. What the public version does not disclose is also stated: the concrete hypothesis organisation, validation strategy, evaluation rules, model collaboration mechanism and factor implementations are the core technology and are not in the document.

Where the project is the wrong tool

The limits are concrete and mostly structural. First, nothing here can be run. A team that wants to evaluate the system on its own data cannot, because the repository holds documents and assets rather than code, and the technical detail that would let you judge the implementation, the validation rules and the factor code, is deliberately withheld. Second, the licence. The README badge labels the project as BSL 1.1 and states in the badge text that it is not open source, and GitHub records the licence identifier as one it cannot classify, so the terms in the LICENSE file are what decide your use, and this is not a project you can fork. Third, the scope is fundamental research. A team whose problem is execution latency, market microstructure, or factor evaluation on a daily rebalance schedule is not the audience described here. Fourth, the ambition is deliberately narrow. The README rules out bulk formula generation, which also means it will not do the thing some buyers of an AI research tool expect, and it places a human at the decision points, which changes the economics for a team that wanted to remove the analyst from the loop rather than support them.

Editorial conclusion

Read Loopera if you are assembling a fundamental research process and want to see how one team has ordered hypothesis formation, validation gates and memory, because the repository documents that thinking in detail even though it gives you nothing to run. Do not adopt it as a tool: the repository states that it is not a source distribution and offers no runnable code, installation package, CLI or public API. If you need a working system, check loopera.cn and the linked technical PDF, and confirm the licence terms in the LICENSE file before using anything from it commercially.

Frequently asked questions

Official sources

1. Issues
2. Loopera-ai/loopera on GitHub
3. Project website
4. README