Other section headings are title case

Also this makes for a long sentence. The parenthetical statement could just stand alone I think:

subject to monotonically guarantees.
No manipulation of a capability ...

This list mixes grammatical forms; we should consistently use one.

I prefer the way imperative reads in general (i.e., changing the others, not this one) but the introduction to the list would then need to change. Either way they should be consistent.

Further to this, we have two use cases for this information

• what is pointer provenance?
• what do I need to do to write correct code?

Pointer provenance in general is a correctness concern (e.g. compiler UB), but the harder requirements in alternate mem* functions are not obvious outside of CHERI. So maybe a section of specific rules:

• Move pointer values only through pointer types or intptr_t/uintptr_t, never through other integer types.
• When you copy memory that may contain pointers, use a provenance-preserving copy (memcpy, memmove, copyinptr, copyoutptr); use the _data variants only for raw bytes where you specifically don't want pointers carried along.
• If you only need the numeric address, use ptraddr_t.

...

Except "Type sizes" immediately above.

Fair enough, but Endianness and Char Signedness below is title case. If not-title-case is the way we want to go we should subsequently change the others.

"direct access" was a bit ambiguous to me, maybe this suggestion is more explicit?

It's certainly possible to add one, but I don't think it would have major value.

I mostly added a mention of qsort to point out that it's not just copying that needs to be tweaked. It might be better to drop it and keep that in the cheri(7) phk suggested.

I've gone and made it somewhat more consistent in D57820. The tree overall is fairly inconsistent on a file-by-file bases with sentence-case, title-case, and capitalize-all-the-things case.

Maybe "Specifically:" or "To do so:"

Make sense to make these imperative to match the first list maybe?

This introductory paragraph is IMO more confusing than the dictionary definition of the 'provenance'.
Could you reuse some text from the standard referenced below, even if not literally?

Esp. useful is the note that provenance is used by optimizers to automatically infer no-aliasing.

why char * is in parenthesis, but intptr_t's are not?

AFAIR 'one past size' is allowed, no?
And, is it requirement for the address at all, or pointers (as distinguished by the text)?

One past the end is allowed, yes. And yes. Should be something like "Avoid manipulating pointers such that they have an address that is neither within the underlying allocation nor one past the end of it."

Is "one past the end" a CHERI specific thing, or listed in a working group doc proposal for C standard or something else?

That's an ISO C requirement, and "one past the end" is used in some places of the ISO spec (sometimes also "one past the last element")

char * is a pointer type (and usually the one you want to use if you're doing math that doesn't require an integer type). intptr_t and uintptr_t are integer types with the guarantee that you can round-trip a pointer through them.

That being said, I agree this is an awkward construction.

I've added a mention of one past the end. I've waffled and not added a mention that de facto C does allow this which is why big CHERI (RV64Y or Morello vs CHERIoT) does allow pointers to go somewhat out of bounds.