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.
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 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 (Base Sepolia)
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 Sepolia (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 Base Sepolia EAS contract, 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 Base Sepolia 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 currently verify on Base Sepolia; 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.