The iPulse architecture starts with classified data before AI

This is the high-level flow: iPulse first classifies the subject and record universe, then builds a versioned historical data layer, then assembles AI configurations, and only then produces forecasts that can be inspected later through lineage and Config Details.

The foundation of iPulse is correct classification of the thing being analyzed, the records attached to it, the ETL process that prepares those records, and the platform data bucket that stores them. AI only becomes useful after the platform knows what the subject is, which data bucket it belongs to, which records are available, and which configurations are allowed to act on it.

This matters because a public equity, a currency pair, a macro indicator, a weather event, and a sports team are not the same forecasting object. They can all be subjects in a broader intelligence system, but each one needs different identifiers, data records, eligibility rules, and output formats.

In user-facing finance pages, iPulse usually says asset because the product is centered on equities, crypto, commodities, indices, funds, foreign exchange, and related market instruments. Internally, the broader word is subject. A subject is the general object of analysis; an asset is one important financial kind of subject.

That distinction lets iPulse expand without rebuilding the core ontology. A company stock can be a subject, but so can a country, city, industry, weather system, political event, economic indicator, sports team, or other forecastable entity once the corresponding records and permissions are supported.

The active public focus is finance and macroeconomy because those domains are commercially useful and already have dense historical records. The underlying sector taxonomy is broader: Financial Markets, Real Estate, Macroeconomy, Politics, Environment, Health, and Sports are all part of the long-range subject map.

Macroeconomy is the system term for economic and state-of-the-world context. It can include indicators such as inflation, employment, income, demographics, social conditions, geopolitical events, tariffs, unrest, or policy shocks. Politics can also be treated as its own subject sector when the forecast target is a policy, election, government relationship, or political risk question rather than general macro context.

Environment covers location and phenomena such as weather, climate, pollution, and physical conditions. Future extensions can add deeper support for real estate, health, sports, and other domains where the same discipline applies: define the subject, classify records, preserve lineage, then forecast.

Inside the current financial priority area, iPulse does not treat all data as one blob. Financial forecasts depend on multiple categories that behave differently, update on different schedules, and carry different reliability profiles.

A helpful way to read this is: the subject is what we forecast, while the record type is the kind of evidence we attach to that subject. Market records tell us how price behaved. Fundamentals tell us how the business or instrument is performing. News, sentiment, and events explain what changed in the world around it. Governance and observability records explain whether the data can be trusted and later audited.

For a non-technical user, record categories are like labeled folders. Price history goes in one folder, company financials in another, news and social signals in another, and audit records in another. That makes it easier to explain what an AI Agent was allowed to see and what kind of evidence shaped the answer.

For finance and AI practitioners, the same taxonomy is an engineering control. A market time series, a scraped article, a provider sentiment score, an earnings transcript, a schema definition, and a changelog cannot be validated, cached, sampled, summarized, or injected into prompts the same way. They need different freshness checks, transformation logic, lineage labels, and output contracts.

iPulse pulls data from data partners, exchanges, and internal processing pipelines on scheduled cycles. The docs intentionally do not name individual suppliers, because provider mix can change and some relationships are operational rather than public brand claims.

Incoming data is screened for freshness, completeness, schema fit, unusual gaps, duplicate records, and basic health signals inside the ETL layer. Ingestion, QA, transformation, preprocessing, cleaning, normalization, and validation happen before records are promoted into durable data-platform buckets.

The data architecture separates core information buckets such as Historic Data, Analytics Data, Feature Data, Prediction Data, and Simulation Data. Control records then describe the operating layer around those buckets: schema registries, registers, reference data, monitoring, logs, changelogs, and later audit evidence. It also tracks lineage, such as primary supplier, secondary supplier, source of truth, exact copy, packaged copy, analytics derivative, feature derivative, and prediction-generated datasets.

Over the last three years, iPulse has redesigned major parts of its architecture from the ground up multiple times. As the product grew from simpler market-data and forecast surfaces into a broader AI intelligence platform, the architecture had to keep changing to support the ambition: more asset categories, more data families, deeper AI Agent configuration, better lineage, stronger serving paths, and clearer user-facing transparency.

Those redesigns were not cosmetic. They came from live data and product complexity. Market data arrives with corporate actions, revisions, stale adjusted values, provider gaps, duplicate records, excessive precision, and occasional impossible values. The platform therefore treats data preparation and auditability as part of the methodology, not as background plumbing.

Once the subject and historic context are ready, the prediction layer assembles the AI side: an AI Agent profile, a task configuration, prompt assembly, input data, output schema, horizon, and validation rules. The model belongs to the AI Agent profile, while the execution mode belongs to the task configuration.

AI Agents are the public label for what product surfaces may also call advisors. Their personas and archetypes are deliberately selected for analytical diversity, then paired with model/backend choices, specialization heads, vocabulary, and asset-class fit. This is how iPulse separates value ownership, macro cycles, political power mapping, forensic skepticism, technical and quantitative thinking, technology futurism, scientific reasoning, and other specialized lenses.

In implementation terms, the AI Agent is not only the famous-name persona. It is the governed combination of persona, archetype, model/backend assignment, mode, asset-class reasoning head, subject-fit constraints, task rules, and output schema. Those combinations already create 100+ AI Agents, and the inventory can expand as new frontier LLM models and additional specialized heads are released, tested, and approved.

The architecture also separates psychological and communication dimensions. Cognitive style, mood, tone, lexical register, thinking horizon, asset-class specialization, subject-fit constraints, and model selection can all influence how an AI Agent reasons and explains a forecast.

A forecast is only useful if iPulse can later explain the configuration behind it. Lineage links the subject, sector, record categories, data version, AI Agent profile, model/backend assignment, task config, mode, prompt assembly components, input format, output schema, generation batch, and forecast horizon.

This is why the Config Details modal exists inside the product. Eligible signed-in users can inspect the configuration used for a specific prediction without exposing proprietary full prompt text or private operational records.

iPulse is designed so past forecasts do not disappear into a black box after the next batch runs. On individual asset pages, eligible users can use the prediction batch selector to open prior forecast batches produced by the AI Agent swarm for that asset.

When a previous batch is selected, the experience is not reduced to a static archive line. The user can inspect the historical advisor reports, visual forecast outputs, deep analysis, ratings, thesis fields, scenarios, risk notes, and batch-level context as they existed for that run.

This creates a practical accountability layer: users can compare what iPulse said at a specific point in time against what happened later, while also inspecting the configuration lineage behind that forecast where their subscription and asset access allow it.