Temporal Granularity

Temporal granularity exists on a spectrum from coarse to fine. Coarse granularity (e.g., calendar year) is sufficient for high-level reporting but cannot express precise deadlines. Fine granularity (e.g., millisecond) enables exact sequencing but increases computational complexity.

• Year-level: Fiscal reporting, long-term obligations
• Day-level: Standard contract deadlines, notice periods
• Second-level: High-frequency trading, real-time compliance
• Millisecond-level: Distributed ledger timestamps, event ordering

A granularity mismatch occurs when two temporal expressions in a contract operate at different levels of precision, creating ambiguity. For example, an obligation effective 'January 2027' combined with a deadline of 'January 15, 2027, 11:59 PM EST' creates an unresolvable temporal relationship without explicit conversion rules.

• The coarse date must be upcast to a finer granularity using default conventions
• Common defaults: first moment of the period (00:00:00.000) or last moment (23:59:59.999)
• Mismatch resolution is a critical step in date normalization pipelines

ISO 8601 is the international standard for representing dates and times, providing a unified framework for expressing temporal granularity. It defines a hierarchical notation where precision is explicit in the format string.

• 2027 — year precision only
• 2027-01 — month precision
• 2027-01-15 — day precision
• 2027-01-15T23:59:59Z — second precision with UTC offset
• Truncation rules ensure unambiguous interpretation when converting between granularities

In temporal logic systems, granularity determines which propositions can be meaningfully expressed. A system with day-level granularity cannot reason about intra-day event ordering, while a system with second-level granularity can detect temporal contradictions that coarser systems miss.

• Allen's Interval Algebra assumes a uniform granularity across all intervals
• Discrete temporal models require explicit granularity selection before reasoning
• Choosing overly fine granularity creates computational overhead without proportional benefit for most contract analysis tasks

Bitemporal modeling tracks two independent time axes, each with its own granularity requirements. Valid time (when a fact is true in the real world) often uses day-level granularity for contract effective dates. Transaction time (when the fact was recorded) typically requires millisecond precision for audit trail integrity.

• Valid time granularity: driven by legal requirements and contract language
• Transaction time granularity: driven by system architecture and compliance needs
• The two axes operate independently, enabling point-in-time queries at different resolutions

Converting between granularities requires deterministic rules to avoid ambiguity. Upcasting (coarse to fine) requires choosing a default moment within the period. Downcasting (fine to coarse) involves truncation and potential information loss.

• Upcast defaults: start-of-period (inclusive) or end-of-period (inclusive)
• Downcast truncation: 2027-01-15T14:30:00Z → 2027-01-15 (time component discarded)
• Business day conventions add complexity: a day-level date must resolve to a specific second when combined with market close deadlines

The computational process of parsing heterogeneous date expressions from legal text and converting them into a single, unambiguous standard format like ISO 8601. Temporal granularity defines the target precision of this normalization—a system configured for day-level granularity will truncate timestamps, while second-level granularity preserves full datetime values. Without strict normalization, a contract referencing 'Q1 2024' and another referencing '2024-01-15' cannot be temporally compared.

A calculus defining thirteen mutually exclusive relations between two time intervals—such as before, meets, overlaps, and during. The choice of temporal granularity directly determines which relations are computable. At coarse granularity (e.g., calendar years), two events may appear simultaneous. At fine granularity (e.g., milliseconds), a strict 'before' ordering emerges, enabling precise sequencing of contractual obligations.

A database design pattern tracking data along two independent time axes:

• Valid time: When a fact is true in the real world (e.g., a contract's effective period)
• Transaction time: When the fact was recorded in the system

Temporal granularity must be specified independently for each axis. A contract management system might record valid time at day granularity but transaction time at microsecond granularity for audit precision.

A directed graph where nodes represent contractual events or deadlines and edges represent precedence constraints. The graph's analytical power depends on granularity alignment—if one obligation is expressed at month granularity ('by March 2025') and its successor at day granularity ('within 5 business days'), the system must resolve this mismatch before computing the critical path. Inconsistent granularity is a primary source of temporal contradiction.

A method of analyzing event streams to detect meaningful temporal patterns in real time, such as a sequence of missed payments triggering a default clause. CEP engines require explicit granularity configuration—a pattern looking for 'two late payments within 30 days' demands day-level granularity on event timestamps. Coarser granularity would collapse distinct events into the same time bucket, preventing pattern detection.

A W3C standard ontology providing a vocabulary for describing temporal properties of entities, including instants, intervals, and their relations. OWL-Time explicitly models temporal granularity through the :unitType property, allowing knowledge graphs to declare whether a temporal entity is expressed in seconds, days, or years. This semantic clarity enables cross-jurisdictional reasoning where legal systems operate at different temporal resolutions.