No, you do not have that. For starters, it's still a matter of debate whether the world is wholly ECMA-48:1976 yet. There are people who contend that we cannot assume universal adherence to a 1976 standard.
Then there's the matter that only colours 0 to 7 are in fact standardized in ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been standardized, and what has been standardized in the likes of ITU T.416 is both not the AIXTerm mechanism and badly implemented to the extent that people are still today pushing for two long-standing mistakes to be corrected by software authors.
Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR control sequences. Famous and still widely used terminal emulators, such as the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing colour; in contrast to many terminal emulators where boldface means boldface and isn't a colour change. The control sequences are not the same and cannot be hardwired.
Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at minimum as long as one allows for "dumb" as well. But that doesn't mean further assuming the AIXTerm 16-colour mechanism. Until you go and change the Linux KVT's (and others') handling of boldface, and then the "linux-16color" entries in termcap and terminfo, to actually match your claim, your claim will remain incorrect.
Then there's the fact that a decent common TUI palette system wouldn't be 16-colour-to-RGB, because that would still need a second map. It would be better than that. That's just a barebones concept. It would be display-element-to-RGB, learning from the design of GUI palettes back in the 1980s, where the colour schemes specified colours for abstract UI elements such as "window title", "pressed button", "file", "directory", "text label", and the like. And indeed from the design of Borland TurboVision, which did the same.
* https://unix.stackexchange.com/q/548158/5132
* https://unix.stackexchange.com/a/5802/5132
Then there's the matter that only colours 0 to 7 are in fact standardized in ECMA-48. That's 8 colours, not 16. The AIXTerm mechanism has never been standardized, and what has been standardized in the likes of ITU T.416 is both not the AIXTerm mechanism and badly implemented to the extent that people are still today pushing for two long-standing mistakes to be corrected by software authors.
Moreover, not every terminal agrees on how to interpret even the non-T.416 SGR control sequences. Famous and still widely used terminal emulators, such as the Linux built-in one for its KVTs, respond to boldface (SGR 1) by changing colour; in contrast to many terminal emulators where boldface means boldface and isn't a colour change. The control sequences are not the same and cannot be hardwired.
* https://unix.stackexchange.com/a/608930/5132
Personally, I am of the opinion that one can nowadays assume ECMA-48:1976 at minimum as long as one allows for "dumb" as well. But that doesn't mean further assuming the AIXTerm 16-colour mechanism. Until you go and change the Linux KVT's (and others') handling of boldface, and then the "linux-16color" entries in termcap and terminfo, to actually match your claim, your claim will remain incorrect.
(Also note the caveats at https://news.ycombinator.com/item?id=23752827 .)
Then there's the fact that a decent common TUI palette system wouldn't be 16-colour-to-RGB, because that would still need a second map. It would be better than that. That's just a barebones concept. It would be display-element-to-RGB, learning from the design of GUI palettes back in the 1980s, where the colour schemes specified colours for abstract UI elements such as "window title", "pressed button", "file", "directory", "text label", and the like. And indeed from the design of Borland TurboVision, which did the same.