lseg-data

## Contents

- [Query Enforcement](#query-enforcement)
- [Quick Start](#quick-start)
- [Authentication](#authentication)
- [Core APIs](#core-apis)
- [Key Field Prefixes](#key-field-prefixes)
- [RIC Symbology](#ric-symbology)
- [Rate Limits](#rate-limits)
- [Additional Resources](#additional-resources)

# LSEG Data Library

Access financial data from LSEG (London Stock Exchange Group), formerly Refinitiv, via the `lseg.data` Python library.

## Query Enforcement

### IRON LAW: NO DATA CLAIM WITHOUT SAMPLE INSPECTION

Before claiming ANY LSEG query succeeded, follow these steps:
1. **VALIDATE** field names exist (check prefixes: TR., CF_)
2. **VALIDATE** RIC symbology is correct (.O, .N, .L, .T)
3. **EXECUTE** the query
4. **INSPECT** sample rows with `.head()` or `.sample()`
5. **VERIFY** critical columns are not NULL
6. **VERIFY** date range matches expectations
7. **CLAIM** success only after all checks pass

This is not negotiable. Claiming data retrieval without inspecting results is LYING to the user about data quality.

### Rationalization Table - STOP If You Think:

| Excuse | Reality | Do Instead |
|--------|---------|------------|
| “The query returned data, so it worked” | Returned data ≠ correct data | INSPECT for NULLs, wrong dates, invalid values |
| “User gave me the RIC” | Users often use wrong suffixes | VERIFY symbology against RIC Symbology section |
| “I’ll let pandas handle missing data” | You’ll propagate bad data downstream | CHECK for NULLs BEFORE returning |
| “Field names look right” | Typos are common (TR.EPS vs TR.Eps) | VALIDATE field names in documentation first |
| “Just a quick test” | Test queries teach bad habits | Full validation even for tests |
| “I can check the data later” | You won’t | Inspection is MANDATORY before claiming success |
| “Rate limits don’t matter for small queries” | Small queries add up | CHECK rate limits section, use batching |

### Red Flags - STOP Immediately If You Think:

- “Let me run this and see what ha