Essentially it is a way to configure a function like (actions: D.ActionT[]) => D.AssertionT[]. It is needed because Assertions may exist for a step that are not supported by a single Action alone. (NB: is this even true? See if we can get any examples where this is desired.)
Use case
Without this behavior, only trivial assertions can be created when using graph-walking logic, and we must make assumptions about them. For example we currently state that a step produces reviewed status if and only if there is a review action. It is necessary however for docmaps to be able to produce assertions based on multiple actions or actions of various types. Therefore the logic is itself a plugin or configuration that should have one or more standard modules for it.
Proposed solution
Needs investigation. Since assertions are not a standard part of the actions themselves, to introduce canonical logic around this based on assumed additional keys in an action would be unwise.
Additional information
This might belong in the SDK, if the graph-walking logic is there instead of in the ETL directly.
Feature Request
Packages to improve:
Description
Essentially it is a way to configure a function like
(actions: D.ActionT[]) => D.AssertionT[]. It is needed because Assertions may exist for a step that are not supported by a single Action alone. (NB: is this even true? See if we can get any examples where this is desired.)Use case
Without this behavior, only trivial assertions can be created when using graph-walking logic, and we must make assumptions about them. For example we currently state that a step produces
reviewedstatus if and only if there is areviewaction. It is necessary however for docmaps to be able to produce assertions based on multiple actions or actions of various types. Therefore the logic is itself a plugin or configuration that should have one or more standard modules for it.Proposed solution
Needs investigation. Since assertions are not a standard part of the actions themselves, to introduce canonical logic around this based on assumed additional keys in an action would be unwise.
Additional information
This might belong in the SDK, if the graph-walking logic is there instead of in the ETL directly.