Yeah, I knew I could do that. If we break open something like the Excel to DMN converter, we would see how the tables are constructed and go from there. I suppose conceptually it wouldn't matter.
Moreover, what would one do if the DMN table were scattered amongst disconnected Camunda instances? It's probably better to pull a master, modify, validate, and push. If you automate all that, which isn't terribly difficult, then from a user standpoint it wouldn't matter whether you did it via a fancy, local Java API call or just rebuilt the thing in one place and deployed it via the REST interface.
We were speculating about what it would take to build a database to DMN dynamic interface where the DMN would be backed by a database which you could manipulate with all the available tools,but which the engine could use to do its evaluation. That's probably a stupid idea given the caching and optimization Camunda have already done.
However, I told my boss I would investigate what could be done programmatically. Our challenge is that you can't restrict a user to modification of individual rules through the Camunda authorization system. Therefore, we'd have to build a front end that allow them only to modify rules that they should have access to. And yes, I know, we could create separate tables and secure each resource, but then you have a "normalization" problem where you have 20 tables all containing the same type of data and rules, divided up just for access control.
My Java and EE knowledge isn't anywhere near what yours is, but my intuition says something like this should be possible. I just wondered if Camunda had already done something to facilitate it.