revisionDate helps place changes in chronological context. It can support freshness and lifecycle interpretation, but it does not by itself establish correctness, trust, verification, or reliability.

MSP-1 v1.0.1 allows revisionDate as either a string or a structured object. The string form is preferred when revisionDate appears as a simple field inside a revision object. The object form is available when lifecycle-date metadata needs additional context.

String form

The string form should be used when a date or date-time value is sufficient.

{
  "revisionDate": "2025-01-10"
}

A date-time value may be used when time-level precision is useful.

{
  "revisionDate": "2025-12-11T14:32:00Z"
}

Object form

The object form should be used when the lifecycle role, precision, timezone, or label needs to be declared.

{
  "revisionDate": {
    "value": "2025-12-11T14:32:00Z",
    "kind": "updated",
    "precision": "datetime",
    "timezone": "UTC"
  }
}

• value — required. The date or date-time associated with the revision or lifecycle event, typically in ISO 8601 format.
• kind — required. The lifecycle role this date plays, such as created, updated, reviewed, published, deprecated, effectiveFrom, effectiveUntil, or other.
• precision — optional. Indicates whether the value is date-only or a full date-time.
• timezone — optional. Timezone identifier or offset when relevant.
• label — optional. Human-readable label for the revision date.
• notes — optional. Additional context about the revision date.
• lastUpdated — optional. Date when the revisionDate record itself was last reviewed or updated.

• revisionDate values should use ISO 8601-compatible date or date-time formatting.
• A revisionDate should remain stable once recorded unless the original record was incorrect.
• revisionDate should support coherent chronological ordering of revision events.
• Date-only values are acceptable when exact time is unnecessary or unknown.
• revisionDate should inform freshness and temporal context but should not be treated as proof of correctness, trust, verification, or ranking value by itself.

{
  "revisionDate": "2025-01-10"
}

String revision date-time:

{
  "revisionDate": "2025-12-11T14:32:00Z"
}

Structured revision date:

{
  "revisionDate": {
    "value": "2025-12-11T14:32:00Z",
    "kind": "updated",
    "precision": "datetime",
    "timezone": "UTC"
  }
}

Revision object with revisionDate:

{
  "revision": {
    "id": "rev-2025-03",
    "revisionDate": "2025-12-10",
    "revisionNotes": "Corrected terminology and added citation.",
    "revisionVersion": "1.0.3"
  }
}

• revision identifies the documented change event associated with the date.
• revisionNotes explain what changed in the revision.
• revisionVersion labels the version associated with the revision event.
• version identifies a declared version for a broader resource, implementation, or protocol-related context.
• provenance may provide origin or lineage context for the change event.
• reviewer may identify review responsibility associated with the revision event.
• trust is a separate interpretive signal and should not be inferred from revisionDate alone.

The deprecated compliance term should not be emitted in new MSP-1 v1.0.1 declarations. revisionDate metadata should not reactivate compliance language or imply that recency alone establishes trust, credibility, or correctness.

Older examples that place precision beside a string revisionDate may receive advisory compatibility handling, but new structured date metadata should place precision inside the revisionDate object.

When revisionDate appears as a field inside a revision object, a valid ISO 8601-compatible string should be accepted. When revisionDate is represented as a structured lifecycle-date object, value and kind should be required.

Validators should flag malformed dates, contradictory dates, impossible chronology, unsupported lifecycle kinds, or incompatible precision placement as non-ideal structural conditions.