Feature Request: Add Sample Anonymized Financial Datasets for Testing and Demos

[nayar-900]

Problem Statement

Many users want to evaluate the financial analysis and equity research workflows before connecting real financial systems or proprietary datasets.

Currently, new users must provide their own data sources, which makes it harder to explore the capabilities of the repository, test workflows, or learn how different components interact.

Proposed Solution

Provide a collection of sample anonymized financial datasets and demo scenarios that can be used for:

• Portfolio analysis
• Equity research examples
• Risk assessment workflows
• Financial reporting demonstrations
• Testing integrations without exposing sensitive information

Suggested additions:

• CSV sample datasets
• Example analysis reports
• Mock company financial statements
• Demo workflow documentation

Benefits

• Faster onboarding for new users
• Easier testing and validation
• Better educational value
• Reduced dependency on proprietary financial data
• Improved reproducibility for examples and tutorials

Use Case

A user evaluating the repository could run a complete financial analysis workflow using sample data before connecting production systems or confidential datasets.

This would make it much easier to understand the platform and verify that installations and integrations are working correctly.

Additional Context

Many data and analytics projects provide demo datasets to help users get started quickly. Adding a small set of anonymized financial examples would improve accessibility and adoption.

[mheilimo]

I would package each demo as a versioned evaluation pack, not only a folder of sample CSVs. That makes correctness measurable before a user connects real systems.

A compact layout could be:

• manifest.yaml: scenario ID/version, domain, synthetic-versus-anonymized flag, license, as-of date, source vintages, intended tasks, and forbidden conclusions
• inputs/: raw statements, positions, market snapshots, and narrative documents
• expected/claims.jsonl: claim ID, type, supporting file/row/period, calculation method, confidence, and known gap
• mutations/: one-variable variants for restatements, stale prices, missing files, unit changes, and contradictory disclosures
• checks/: deterministic arithmetic and provenance assertions, separate from any preferred report wording

Useful acceptance cases would verify that:

1. Statements cross-foot before analysis starts.
2. Every material number resolves to an exact file, row, period, currency, and unit.
3. A planted contradiction remains visible rather than being averaged away.
4. Missing inputs produce explicit gaps, not invented values.
5. A restated source invalidates only dependent claims and records the delta.

Fully synthetic packs are usually safer and more reproducible than lightly anonymized customer data; the manifest should make that distinction explicit.

I work on DDScore at Playful Pixels Oy. One adjacent private-company fixture could combine a synthetic pitch deck, financial note, founder assumptions, and time-stamped public-source snapshots. Our structured investor workflow turns submitted private-company materials and current public-source cross-checks into a 0–100 analysis across 12 dimensions and a written report. The fixture would help test completeness and evidence/inference separation. DDScore supports human judgement; it is not investment advice or a replacement for full diligence.