We imagine defining a set of primitive operations that are not necessarily valid Lisp operations, but rather lower-level primitives that higher-level Lisp functions can be defined in terms of.
For instance, instead of defining car as a function known to the compiler, we could define it like this:
(defun car (object)
(assert (or (null object) (consp object)))
(if (null object)
nil
(sys:load-mem (sys:mask object) 0)))
This function would be declared inline, so that the compiler will have access to the body of code whenever car is used in application code. If the compiler can prove that the object is of type cons, then the assert and the test can be skipped, leaving just the calls to sys:load-mem and sys:mask. These functions will be implemented as one or a few assembly instruction on most processors.
In order for code to be safe, the compiler would have to check that no references are made to the low-level primitives directly by application code. This can be done by using the Gracle protection mechanism to prevent unprivileged code from accessing symbols in the sys package.
Using low-level primitives like sys:load-mem makes it much easier to write low-level code required in tools such as a debugger or a backtrace function without resorting to C or assembler.
Other Lisp primitives such as elt, aref, etc. could be defined in a way similar to that of car above.