rendering intent
A rendering intent is the rule that says what becomes of a colour the destination cannot hold.
In more detail
No device holds every colour. A screen reaches greens a press never will; a press on uncoated paper reaches far fewer than a screen. So moving a picture from one to the other always leaves colours with nowhere to go, and something has to be decided about them.
Four rules exist. Two keep every colour that fits exactly and clip the rest, differing only in what they do with white: one holds the source's white, the other moves everything so that white becomes the paper. One keeps colours vivid rather than exact, which is what a bar chart wants — nobody measures the blue of a bar. And one moves every colour, those that would have fitted included, so that the distances between them survive; a photograph wants that one, because the eye reads the relations between colours long before it reads any single colour.
What it does on a real document
A declared graphics state sets `rendering_intent`, taking `absolute_colorimetric`, `relative_colorimetric`, `saturation` or `perceptual`, and a drawn shape applies that graphics state by its name. A second JSON key goes beside it: `black_point_compensation`, which says whether the conversion takes the darkest tone of the source into account, and which is what keeps the shadows of a photograph from closing up into flat black.
Saying nothing is common and is not a mistake: the conversion then follows whatever the profile and the program showing the document settle between them. Stating it is for the job that has been proofed and has to come back the same.
Where it comes from, and why
The four rules were written into the ICC profile format at the beginning of the nineteen-nineties, when colour management stopped being each manufacturer's private business. The names are the ones that specification uses, and every program that converts colour has used them since.