Define a Reliable Trade-Reconciliation Library Contract

Design the parsing and domain boundaries of a trade-reconciliation library that identifies unmatched buy/sell records. Explain how timestamp tolerance, partial fills, and malformed data affect the contract before implementing matching. ### Constraints & Assumptions The source reports reconciliation coding and OOP discussion but does not disclose the matching fields, tie policy, partial-fill rules, or file grammar. This exercise preserves the supported engineering discussion; it does not invent a specific executable matching problem. ### Clarifying Questions Which fields identify compatible trades? Is matching one-to-one or can quantities split across fills? What timestamp unit, timezone, and tolerance apply? If several matches are possible, which pairing objective and tie rule are intended? Is input batch or streaming? ### What a Strong Answer Covers Parsing separate from domain validation, typed exact values, explicit matching policy, traceable breaks, clear ownership of state, and tests that distinguish timestamp and pairing semantics. ### Follow-up Questions Why is exact timestamp equality inappropriate under the reported tolerance requirement? What if tolerance makes several candidates eligible? How do late records or duplicate inputs affect a break already reported?