@cjmurphy hello, the way pathom resolve transitive deps is by walking the index, with reader2 and parallel-reader, they use a compute-plan function which figures the paths available to go from the data you have to the one you asked, it walks in a reverse way, trying to think of your example, this is what your resolver looks like?

(pc/defresolver org-data [_ _]
  {::pc/input  #{:organisation/id}
   ::pc/output [{:organization/time-info
                 [:time-info/current-period]}]}
  ...)

No the org-data resolver output just has

[{:organization/time-info
                 [:time-info/id]}]

Also my readers are just these: [p/map-reader pc/reader2 pc/open-ident-reader], so no parallel-reader .

yeah, the reason why you can't ask for :time-info/current-period is that Pathom never switch context, so, there are sibling and nested dependencies, in your case there is a nesting, so since you may have multiple links like this (returning same properties for different entities) Pathom will not try to pull data from nested resources

that said, if you want to make that possible, one extra resolver can do it, like:

(pc/defresolver organization-time-data [env {:organization/keys [time-info]}]
  {::pc/input  #{:organization/time-info}
   ::pc/output [:time-info/id
                :time-info/current-period]}
  time-info)

but if that's the case (you don't have multiple assotiations, being a simple to-one relationship), then your original resolver for organization may already return that flat, if you do so then it just works, makes sense?

I think so. So where I need to nest from organisation just do so in org-data resolver's output, as you did in your first code snippet. So along with :time-info/id there will also be :time-info/current-period . Then Pathom will understand that that nesting can be done. I'll try that. Are 'subling' dependencies fine? Still not sure the definition of that. Still getting to grips with Pathom, not there yet...