Since the earliest vestiges of capability design it has been possible to pass capabilities in messages. Yet there are some ramifications that have not been described as far as I know. When you send me a capability parameter P, have I any means of knowing what it means to invoke P other than what you tell me? I may need better assurance of some critical properties of P. Invoking P tells me nothing beyond what you tell me about P; I must assume that P replies just as you have programmed it to reply. Keykos, and earlier systems I think, provide certain means for me to draw some conclusions about P beyond what you tell me.

What I do with P to gain such assurance has many names. Here are some:

I make no technical distinctions here; each expression has useful connotations.

Means for me to ‘examine’ P seem all to fall into some synergy pattern. Indeed the ramifications I examine here are parallel to the issues of introducing synergy into the platform. In each synergy pattern I rely on some other object that I did not get from you to tell me whether I can safely use P. I pass P to it and it replies yes or no.

Each of these synergy patterns that I have used to solve integrity problems is equivalent to verifying that P is of some particular class, for some ordinary concept of class. More general patterns are possible and perhaps useful.

Why should I care if you sent me a bad form of P; is it my business that the service I provide to you relies on a defective tool P that you provided to me?

Suppose that I provide a shared, stateful, serially reusable service to some clients and you are one of those clients. I am obligated to serve my other clients even after you provide me with a faulty parameter. Here are several reasons I may need to vet P before invoking it:

There are many other such reasons, yet synergy seems to be at odds to unlimited counterfeiting.

I glean from the examples above two sorts of protection provided by synergy:

I can’t think of other classes of reasons just now.
Computers do many useful things that do not require either of these situations. We should consider whether it would be useful to provide a program environment without synergy that allows full synthesizability.

I think that the membrane concept bears on these issues but I have not seen it developed well enough yet.

Contrast with E’s Auditor Patterns.

Software technologies are nearly always described in some context of implicit background assumptions. These pages try to provide that background but they provide little guidance on where to start reading so that you learn the assumptions soon enough. The discussion above is deep in the Keykos assumptions. These pages are guilty of that and worse, the background is unconventional.

Describing the E auditors ferrets out many of these assumptions and maybe illuminates some of E

Java auditor class, Interface Auditor,