I think it depends on what you mean by "expire". Assuming you just want this document to stay in Windchill, but have users not be able to see it or do anything with it if it expires (except for admins), there may be multiple ways to tackle this.
Off the top of my head I would try making a separate doc type, to get a separate life cycle and workflow, and call it with a separate OIR. While object is in the initial state (say, In Work), the doc can be prepared, etc. Once the doc is ready to be "active", do a set state to the next state (i.e. Released), and have THAT zstate be the trigger to kick off a workflow.
The workflow could do three things in parallel
- Put a workflow task to a user that is used to "renew" the object or "deactivate" it, with those two routing options. "Renew" will essentially reset the two timers (mentioned below), and loop back to this same workflow task to remain dormant until next time. "Deactivate" can set the object to a 3rd lifecycle state (i.e. Inactive). Workflow ends.
- Kick off a timer bot (Timer1) for 335 days. After this timer is up, go to an e-mail bot to send a message and then to ground. Timer2 remains active.
- Kick off a timer bot (Timer2) for 365 days. After this timer is up, go to essentially the same route as "deactivate", which removes the workflow task.
You can then configure ACLs to the life cycle states accordingly to block access to Inactive objects. The nice thing about this method is that you could always reactivate a deactivated object by setting the state back to Released (most likely from up-revising to In Work first, updating the object, then a set state). There may be better/more efficient ways or tools/elements to use, but this is the first thing that comes to my mind within the OOTB realm.