---
feature_story: FS_62_25_92_06
feature_title: manipulating `assigned_context`
feature_status: TODO
---

TODO: TODO_66_66_75_78: Split `arg` to `prop` concepts
TODO: TODO_55_51_89_92: review and update `args_context`
      Merge `assigned_context` and `args_context`? Because plural `args_` is easily singular `arg_`.

TODO: Figure out how to deal with over-specified context.
      How to solve problem when context extra `prop_name` = `prop_value` entry hides `data_envelope`-s
      (which do not contain such entry) from search results?
      Approach - see FS_31_70_49_15:
      The query specifies (`prop_name`, `prop_value`) pairs from `assigned_prop_name_to_prop_value`
      but only those listed in `arg_name_to_prop_name_map`.

The context represents "assigned" (`prop_name`, `prop_value`) pairs list (in fact, {`prop_name`: `prop_value`} dict).

For example, a pre-set (`prop_name`, `prop_value`) pairs could be specifying environment:
*   (`code_maturity`, "dev")
*   (`flow_stage`, "upstream")
*   (`geo_region`, "apac")

Each (`prop_name`, `prop_value`) entry in the context has associated metadata:

*   `ValueSource`: where the `prop_value` comes from.

     Effectively, it specifies priority (whether another source can override) it.

     For example, `ValueSource.explicit_dictated_arg` overrides most of `ValueSource.*`.

*   Last modification actor: who changed this (`prop_name`, `prop_value`) entry.

Each (`prop_name`, `prop_value`) entry in the context can be manipulated:
*   Added if it did not exist yet.
*   Overridden if it already existed (if prev `ValueSource` had higher priority than the next one)
*   Removed if it already existed.
