Skip to content

feat(ledger): Surface fact provenance and align IB queries with TS parity#126

Merged
jfrench9 merged 1 commit into
mainfrom
feature/fact-provenance
May 30, 2026
Merged

feat(ledger): Surface fact provenance and align IB queries with TS parity#126
jfrench9 merged 1 commit into
mainfrom
feature/fact-provenance

Conversation

@jfrench9
Copy link
Copy Markdown
Member

Summary

This PR introduces fact provenance support to the ledger client and brings Interactive Brokers (IB) related GraphQL queries to feature parity with the TypeScript implementation.

Key Accomplishments

Fact Provenance Support

  • Added a new FactSetLiteProvenanceType0 model to represent provenance metadata associated with facts, enabling downstream consumers to understand the origin and lineage of individual facts in a fact set.
  • Extended the existing FactSetLite model to include an optional provenance field, wiring provenance data into the core fact representation.
  • Registered the new model in the models/__init__.py barrel export for clean public API access.

IB Query Parity with TypeScript Client

  • Expanded the ledger GraphQL query definitions to include additional queries that were previously only available in the TypeScript client, ensuring consistent capabilities across both client implementations.

Breaking Changes

  • Potentially breaking: The FactSetLite model now includes a provenance field. If any downstream code performs strict schema validation or serialization that does not tolerate new/unknown fields, it may need to be updated. However, since the field appears to be optional (using a union type with a nullable pattern — Type0), this should be backward-compatible for most consumers.

Testing Notes

  • Verify that existing ledger queries continue to function correctly with the updated query definitions.
  • Confirm that the new provenance field is correctly deserialized when present in API responses, and that it gracefully handles null/absent values.
  • Validate the newly added IB-related queries return expected results and match the behavior of the TypeScript client.
  • Ensure the FactSetLiteProvenanceType0 model correctly parses all expected provenance metadata fields.

Infrastructure Considerations

  • No infrastructure changes required. This is a client-side model and query expansion.
  • Downstream services or pipelines consuming FactSetLite objects may want to opt in to leveraging the new provenance data for audit trails, debugging, or data lineage features.

🤖 Generated with Claude Code

Branch Info:

  • Source: feature/fact-provenance
  • Target: main
  • Type: feature

Co-Authored-By: Claude noreply@anthropic.com

Add `provenance` to the factSet selection, and level the
GetInformationBlock / ListInformationBlocks queries up to the full
envelope standard — rules (incl. ruleTarget / ruleVariables), factSet,
verificationResults, and view — so the Python IB reads match the
TypeScript client field-for-field. Regenerate the FactSetLite model.
@jfrench9 jfrench9 merged commit 3cf54d0 into main May 30, 2026
1 check passed
@jfrench9 jfrench9 deleted the feature/fact-provenance branch May 30, 2026 21:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant