He’s an in-progress hierarchy of what’s needed for information to be most useful to an organization or other multi-agent system. I’m sure there must be other very similar hierarchies out there, but don’t currently know of any quite like this.
Say you’ve come up with some cool feature that Apple could include in it’s next phone. You think this is a great idea and they should add it in the future.
You’re outside of Apple, so the only way you have of interacting with them is by sending information through various channels. The question is: what things should you first figure out to understand how to do this?
First, you need to have identified an improvement. You’ve done that, so you’ve gotten through the first step.
Second, for this to be incorporated, it should make sense from Apple’s perspective. If it comes out that the costs of adding the feature, including opportunity costs, outweigh the benefits, then it wouldn’t make sense to them. Perhaps you could deceive them to incorporate the feature, but it would be against their interests. So you should hopefully get information about Apple’s utility function and identify an intervention that would implement your improvement while being positive in expected value to them.
Of course, just because it could be good for Apple does not mean that the people necessary to implement it would be in favor of doing so. Perhaps this feature involves the front-facing camera, and it so happens that people in charge of the decisions around the front-facing camera have some strange decision function and would prefer not being asked to do more work. To implement your change, these people would have to be convinced. A rough estimation for that would be an analysis that suggests that taking this feature on would have positive expected value for their utility functions. Again, it’s possible that isn’t a requirement, but if so, you may be needing to effectively deceive people.
Once you have expected value equations showing that a specific intervention to implement your suggestion makes sense both to Apple and separately to the necessary decision makers at Apple, then the remaining question is one of what can be called deployment. How do you get the information to the necessary decision makers?
If you have all four of these steps, you’re in a pretty good place to implement the change.
One set of (long-winded) terminology for these levels would be something like:
Improvement identification
Positive-EV intervention identification for agent
Positive-EV intervention identification for necessary subagent
Viable deployment identification
There are cases where you may also want to take one step further back and identify “problems” or “vague areas of improvement” before identifying “corresponding solutions.”
Another note to this; there are cases where a system is both broken and fixable at the step-3 level. In some of these cases, it could be worth it to fix the system there instead, especially if you may want to make similar changes in the future.
For instance, you may have an obvious improvement for your city to make. You may then realize that the current setups to suggest feedback are really difficult to use, but that it’s actually quite feasible to make sure some changes happen that will make all kinds of useful feedback easier for the city to incorporate.
He’s an in-progress hierarchy of what’s needed for information to be most useful to an organization or other multi-agent system. I’m sure there must be other very similar hierarchies out there, but don’t currently know of any quite like this.
Say you’ve come up with some cool feature that Apple could include in it’s next phone. You think this is a great idea and they should add it in the future.
You’re outside of Apple, so the only way you have of interacting with them is by sending information through various channels. The question is: what things should you first figure out to understand how to do this?
First, you need to have identified an improvement. You’ve done that, so you’ve gotten through the first step.
Second, for this to be incorporated, it should make sense from Apple’s perspective. If it comes out that the costs of adding the feature, including opportunity costs, outweigh the benefits, then it wouldn’t make sense to them. Perhaps you could deceive them to incorporate the feature, but it would be against their interests. So you should hopefully get information about Apple’s utility function and identify an intervention that would implement your improvement while being positive in expected value to them.
Of course, just because it could be good for Apple does not mean that the people necessary to implement it would be in favor of doing so. Perhaps this feature involves the front-facing camera, and it so happens that people in charge of the decisions around the front-facing camera have some strange decision function and would prefer not being asked to do more work. To implement your change, these people would have to be convinced. A rough estimation for that would be an analysis that suggests that taking this feature on would have positive expected value for their utility functions. Again, it’s possible that isn’t a requirement, but if so, you may be needing to effectively deceive people.
Once you have expected value equations showing that a specific intervention to implement your suggestion makes sense both to Apple and separately to the necessary decision makers at Apple, then the remaining question is one of what can be called deployment. How do you get the information to the necessary decision makers?
If you have all four of these steps, you’re in a pretty good place to implement the change.
One set of (long-winded) terminology for these levels would be something like:
Improvement identification
Positive-EV intervention identification for agent
Positive-EV intervention identification for necessary subagent
Viable deployment identification
There are cases where you may also want to take one step further back and identify “problems” or “vague areas of improvement” before identifying “corresponding solutions.”
Another note to this; there are cases where a system is both broken and fixable at the step-3 level. In some of these cases, it could be worth it to fix the system there instead, especially if you may want to make similar changes in the future.
For instance, you may have an obvious improvement for your city to make. You may then realize that the current setups to suggest feedback are really difficult to use, but that it’s actually quite feasible to make sure some changes happen that will make all kinds of useful feedback easier for the city to incorporate.