v1

[cbizon]

A document codifying the results of discussions at the start of the performance phase.

[maximusunc]

This is something that David K brought up, but Shepherd will default to using the Retriever interface for any lookups (and we will strongly recommend this interface), but it's entirely possible that an ARA is able to access other knowledge providers or services outside of Retriever.

[cbizon]

Thanks @maximusunc I added a new line that ARAs can access their own internal stuff like databases. @dkoslicki do you think that this captures it or should it be more expansive?

[dkoslicki]

The databases part makes sense. And the It is possible to host non-Shepherd ARAs if desired and this PR does not exclude the possibility. also leaves open the possibility of using an ARAX-style beam-search for lookups instead of retriever directly, like we talked about on the call. So both of these capture it in my mind.

[maximusunc]

The core of Shepherd will be implemented in python, but hopefully individual operations will be more language-agnostic and developers can make new operations in their preferred language.

[cbizon]

Makes sense. I aded a line to that effect. But I did say that python was preferred even in this case. FWIW, I think it's valuable to think about the operations as shared code so that we can have Translator-wide contributions. But I don't feel terribly strongly about it, if people hate it I can amend.