What is it about?
A governed entity and its relationships in the Knowledge Graph.
Concept · Architecture · Standard
How Forecast Library works
The Knowledge Graph identifies what a forecast is about. The target defines exactly what is being predicted. The Open Forecast Receipt preserves the forecast, its forecaster, timing, context, and evidence as one verifiable record.
The concept
A shared memory for forecasts
The Library answers four different questions without mixing them together.
What is being predicted?
A precise target, dimension, unit, cadence, and horizon.
What was forecast?
A forecast sealed with its forecaster, timing, context, and provenance.
Can we trust the record?
Integrity proof now; accuracy evaluation only after the target matures.
Knowledge Graph
Entity, target, and forecast are different objects
An entity is a stable real-world or conceptual thing. A target is a measurable property or outcome applied to that entity. A forecast is one forecaster's prediction for that approved subject-target binding.
Loading interactive knowledge graph…
Knowledge Graph architecture
Identity gives the forecast meaning. The receipt gives it memory.
The Library keeps the real-world subject separate from the measurable target. A forecaster predicts that subject-target binding, and an Open Forecast Receipt preserves the resulting forecast and its provenance.
LegendSchema.org entity typeLibrary entity typeForecast targetDimensionUnit Named relationship
1
Knowledge Graph
Stable identities and typed relationships
Context entity
Alibaba Group
Issuer organization
Corporation issues
Subject entity
BABA ADR
Listed Security
Thing2
Forecast definition
Exactly what will be predicted
Target definition
Adjusted close return
Reusable measurement contract
Dim.: Step-over-step changeUnit: %
applies to subject
Approved binding
BABA + return target
Cadence and horizon are versioned
3
Forecast record
Who predicted what, when, and with which context
Forecaster profile
AI, algorithm, human, or team
Produces a forecast
produces
Forecast
Predicted values
References the approved subject-target binding
sealed as
Open Forecast Receipt
Forecast + provenance
Optionally anchored and later evaluated
Receipt
Preserves the forecast and its provenance
Proof
Confirms integrity and publication timing
Evaluation
Scores the forecast only after the target matures
Concrete examples
The same structure works across domains
Market securities and macroeconomic forecasts use the same entity-plus-target contract.
LegendSchema.org entity typeLibrary entity typeForecast targetDimensionUnit Named relationship
Live catalog example
issues
Subject entity
Alibaba ordinary shares
9988 · Hong Kong
Listed SecurityThing
Adjusted end-of-day close return
Dim.: Step-over-step percentage changeUnit: %
Forecast-ready
issues
Subject entity
Alibaba ADR
BABA · New York
Listed SecurityThing
Adjusted end-of-day close return
Dim.: Step-over-step percentage changeUnit: %
Forecast-ready
One corporation issues two separately identifiable securities. Both can use the same target definition, but each subject-target binding keeps its own forecast history.
Illustrative expansion
Geographic context
United States
Country measures for
Subject entity
United States
US
CountryCountry
Real GDP growth
Dim.: Quarterly · annualized changeUnit: %
Forecast-ready
has institution
Subject entity
Federal Reserve System
United States
Central BankGovernmentOrganization
Federal funds target rate
Dim.: Policy rate levelUnit: %
Forecast-ready
Context can connect several forecasts without becoming their target. GDP is measured about the country; the policy-rate target is measured about the Federal Reserve System.
Receipt lifecycle
From prediction to permanent, inspectable record
The forecaster produces the forecast. The receipt seals it. A blockchain proof may anchor its digest, and evaluation happens only when the target can be resolved.
1
Forecaster
A human, AI model, algorithm, ensemble, hybrid, or organization produces a forecast.
2
Forecast
Predicted values are tied to one approved entity-target binding and horizon.
3
Receipt
The forecast, timing, context boundaries, evidence, and provenance are sealed together.
4
Proof
An optional blockchain attestation anchors the receipt digest without claiming accuracy.
5
Evaluation
After maturity, the forecast is compared with the governed observed outcome.
Public submissions are reviewed manually
The current platform is focused on selected iPulse AI showcase assets. There are no public accounts, payment plans, or automated uploads. To propose a public forecast receipt, email support@ipulseai.com.
How to read a blockchain proof
Follow a public proof from its Base transaction to the forecast values stored in Ethereum Attestation Service (EAS). Reading a proof is free: no wallet, connection, signature, or account is needed.
Already on an EAS attestation page? Skip to step 3. A Forecast Library receipt's View attestation button opens the individual forecast directly. A ledger's See blockchain proof link opens the shared transaction.
This worked example uses Alphabet / Google, Batch 6 on Base mainnet ↗. Each asset and batch has its own transaction and forecast UIDs. Use the proof linked from the forecast you are checking; these example IDs are not its proof.
1. Open Logs and copy the forecast UID
On BaseScan, choose Logs beside Overview. In an Attested event, find Data → uid (bytes32) and copy the complete value. The example shows Logs (12); the number varies with the submission. Each event identifies one forecast, even when several forecasts share one transaction.
The transaction hash identifies the submission. The attestation UID identifies one forecast. The schema UID identifies the shared data format. They are different identifiers.
2. Find that UID on Base EAS Scan
Open Base EAS Scan ↗, paste the UID into its search box, and open the matching attestation result. Add 0x at the start if BaseScan omitted it. BaseScan's event log does not currently provide a direct EAS link.
For this example, use:
0xebe16769d597f16364c4848800cf1c87003c61e130589d9f5a94605ae6da121dOpen the matching Google forecast attestation ↗Check that its UID matches. Near the bottom, Transaction ID should link back to the transaction you started from. A NVIDIA UID will not appear in Google's transaction logs.
3. Read Decoded Data
Scroll to Decoded Data. Confirm the subject, batch, revision, and forecaster before reading the prediction. In this example, ticker:GOOG@XNAS means Google on Nasdaq, Run Number is 6, and Run Revision is 1. The named forecaster is an AI advisor persona using Gemini 3.1 Pro, not a forecast or endorsement by the real person.
| Field | How to read this example |
|---|---|
| Anchor Value Micros | 356180000 ÷ 1,000,000 = $356.18. Anchor Unit is USD. |
| Cadence Months / Point Count | 3 months × 20 points = a five-year path. |
| Step Return Bps | Divide each value by 100 for a percentage. −800 means −8%, not −800%. Returns apply sequentially to the previous point. |
| Forecast Created At / Anchor At | Unix timestamps in seconds: forecast generation time and the starting market observation time. Neither is the blockchain publication time. |
| Created / Retrospective | The explorer's Created time is the onchain anchoring time (display timezone may vary). Retrospective = True means this anchor was published after the forecast. |
| Receipt Digest | The SHA-256 fingerprint linking this onchain projection to the complete receipt payload. |
These units describe the current market receipt profile. Other forecasting domains or schema versions may use different fields; always read the linked schema.
4. Compare it with the complete receipt
Open the corresponding Forecast Library receipt and download its JSON. The blockchain contains a compact forecast projection and digest; the receipt contains the fuller context and provenance. To verify the payload independently, canonicalize receiptPayload with RFC 8785 and compute SHA-256. Compare that digest with Receipt Digest on EAS (ignoring only the hexadecimal 0x prefix). Hashing the entire JSON file, including its proof envelope, will not produce the same digest.
What this establishes. A matching verified anchor provides evidence that the committed record existed by its blockchain anchoring time. It does not prove forecast accuracy, authorship, or that a retrospective forecast existed onchain on its original date. Check the network: this example is Base mainnet; Base Sepolia is a separate test network.
Screenshots captured from public BaseScan and Base EAS Scan pages on 12 September 2026. Explorer layouts may change. This is a read-only tutorial.
Technical standard
Open Forecast Receipt v0.1.0
The sections below define the portable JSON contract, deterministic digest, optional blockchain attestation, and current reference implementation.
What is an Open Forecast Receipt?
An Open Forecast Receipt (OFR) is a structured, provenance-aware forecast record defined by the ofr-core-v0.1.0, ofr-market-v0.1.0, and ofr-ai-v0.1.0 profiles. It binds a market prediction (anchor price, cadence, step returns) to cryptographic integrity verification and, when published, to an Ethereum Attestation Service (EAS) record on the network identified by its proof. The live Batch 6 Showcase uses Base mainnet; development examples use Base Sepolia. The goal is transparent, verifiable, and portable forecast data while making the limits of each proof explicit.
OFR Schema v0.1.0
Every OFR follows the JSON Schema at https://ipulseai.com/schemas/open-forecast-receipt/v0.1.0/schema.json. The schema defines five required top-level sections: $schema,specVersion,profiles,receiptPayload, andproofEnvelope. The immutable payload contains receipt identity, issuer, forecast, temporal and generation provenance, evidence, and disclosure. The proof envelope contains the payload digest and independently mutable proofs. The schema uses additionalProperties: false to reject unknown fields.
Stable identity when tickers change
A ticker is a point-in-time market identifier, not the permanent identity of a company or instrument. Each receipt therefore binds an issuer-stable subject.idand snapshots the ticker, MIC, ISIN, and other available identifiers that applied to that forecast. Public asset URLs use a stable navigation slug with optional aliases. If a company changes its ticker, the current subject registry and URL aliases may be updated, while historical receipts, identifiers, digests, and attestations remain untouched.
Digest Computation (RFC 8785 + SHA-256)
The sealed payload digest is computed as follows:
- Select exactly
receiptPayload. The proof envelope is never part of its own digest. - Canonicalize the payload using the RFC 8785 JSON Canonicalization Scheme (
json-canonicalizev2). - Compute the SHA-256 hash of the canonical UTF-8 bytes via the Web Crypto API.
- Compare the hex-encoded digest to
proofEnvelope.payloadDigestSha256.
EAS Attestation on Base
When published, an OFR's key fields (17 fields covering market identity, prediction parameters, and the receipt digest) are encoded as an EAS attestation on Base mainnet (chain ID 8453), or Base Sepolia for test proofs (chain ID 84532), at contract 0x4200...0021. The EAS schema uses bytes32 receiptDigest and is non-revocable. Its deterministic schema UID is 0xfef3868c279700c5312e68d8f5be4cd4a755a5125c3d2153f1970b626e35cc14. The initial retrospective showcase selects 0 receipts across all five public assets; 0 currently have verified attestations.
Blockchain Status
The blockchain status axis shows whether the receipt's digest has been attested onchain. A selected but unissued receipt remains explicitly labeled not_issued. When a real UID is available, the app reads the EAS contract on the proof's declared network, ABI-decodes all 17 fields, and compares the onchain digest against the locally computed digest and reports one of: verified, revoked, pending, or unavailable.
Canonical Fixture: PepsiCo Batch 6 / Ray Dalio
The PepsiCo/Ray Dalio fixture is the canonical data source for this explorer. It represents Batch 6, run 6, revision 2 of the iPulse AI forecast pipeline for PepsiCo, Inc. (PEP:XNAS). The fixture is a retrospective receipt — created after the original forecast was published — and carries issuanceMode: "retrospective". The forecast was generated by the Gemini 3.1 Pro AI model (Google DeepMind), using theRay Dalio / The Strategist / RESEARCHER advisor persona. The 20-step forecast starts with -4.00% and -3.00% step returns. The compact onchain projection stores those same values internally as -400 and -300 basis points so it can use deterministic integers. The terminal reconstructed price is approximately $180.61(anchor $144.22 × compound 25.23% return). Its researcher response was generated at 2026-07-05 14:48:47 UTC. The canonical payload digest is 85e82d4748...60ea4a5.
Data Sources
The public Library reads published collections, subjects, forecast indexes, receipts, and proof metadata from Cloud Firestore. The original reviewed Batch 6 JSON examples remain only as immutable test vectors and as the one-time source for the controlled Firestore import; the running application does not use them as its database. A network-specific RPC read occurs only when a receipt has a non-null attestation UID.
Limitations
- The receipt proves integrity and publication timing, not correctness. A valid digest confirms the document has not been tampered with; it does not validate the forecast's accuracy.
- 0 of the 0 selected showcase receipts have verified attestations. Each proof identifies its network; unselected receipts make no onchain-proof claim.
- All 60 Phase 1 advisor receipts are retrospective examples. Blockchain time must remain distinct from the original forecast time.
- Named forecasters are software advisor personas. The receipt does not claim endorsement by or affiliation with the named person.
- This is an example retrospective receipt. The blockchain timestamp (when issued) must not be presented as the forecast creation time.
- The Batch 6 context snapshot is a reconstructed backfill and is labeled accordingly.
- Researcher web search was configured, but result-level grounding was not retained; actual execution and retrieved evidence remain unknown.
- No real-time market data — the Library preserves published forecast snapshots.
- Public browsing is anonymous and read-only. Publishing and blockchain issuance are restricted server-side operator workflows.
- This is experimental educational content. Not investment advice.
The first reference implementation began during the AI Factory Hackathon with builder.nativelyai.com. It is now maintained by Future Edge Group as the public iPulse AI forecast showcase and open-source verification toolkit.