General

You can trust a factory to stick around and behave in the future as it has in the past, so long as no one mucks with the builder's key to the factory or orders the bank, from which it was built, to disolve. The foundation is designed to provide assurance that on one will be able to disturb a factory.

A foundation refers to some trusted object and holds the only service keys to that object and holds the only bank keys sufficient to disolve its bank.

Foundations come in several varieties depending on the type of object they refer to. Segment, factory and bank foundations have been conceived so far.

These ideas can support those described at (po-integ).

A foundation begins in its "nascent phase". During this phase it may grow (create space) by calling the foundation's bank. Until injunctions are granted (or after they are all relinquished) the guard may be excersized to reclaim the storage.

Space for the segment of the segment foundation, or space for the factory are examples of this type of growth.

Informal Requirements
The builder needs to acquire access to a bank that can be declared invulnerable at some later time. It need not be invulnerable initially. Indeed the product may go thru "beta test" before the bank is made invulnerable. Indeed users of the product may have already built the products that they intend to be invulnerable.

The builder presumably pays something for access to the invulnerable bank, and then pays a great deal more to have it made invulnerable. The second payment "buys the disk". He can presumably sell the bank back whenever he can reacquire all of the injunctions. Indeed we might call this the "lease-purchase" plan.

Tactics
I think that the current bank implementation suffices as follows:

A nascent bank foundation:]
creates a new bank subsiderary to a master bank,] establishes pre negotiated limits on the bank,] exports a bank key lacking "change limits" and "destroy" rights.

Upon sealing the foundation, a new limit of 0 may be established for each of pages and nodes.

This last action is not needed to support integrity, but merely to safeguard the master bank's interest.

A factory foundation holds the only builder's key to its factory. It also holds the only guard key to the bank from which the factory was built. The foundation also holds a set of "vulnerabilities", somewhat like the holes of a factory.

There are also a set of injunctions that refer to the foundation {(fi)}. A foundation knows how namy injunctions there are and will not distruct while any remain.

A factory foundation begins life with a new factory. Calls on the foundation service key are available that are passed thru to the factory builder's key with certain restrictions. Just as undocumented keys can become components of a factory but are then holes of the factory, so may undocumented keys keys be passed thru to the foundation's factory, but they become vulnerabilities of the foundation. A special foundation order accepts the user's key to another foundation and installs that foundation's key as the component. An injunction for the second foundation must also be provided. The second foundations vulnerabilities are added to those of the first foundation. A segment foundation may be passed to a factory foundation to the effect that the segment becomes a component of the factory (again with vulnerability inclusion).

There are two possible goals for the foundation: for the underlying object to outlive the injunctions, or for the underlying object to remain immutable while it lasts. Since there may be some value to the concept of remaining immutable while an objects exists neither of these goals subsume the other. I hope that we can simplify things by always achieving both.

An order on the foundation's user key returns a requestor's key to the factory.

Provide a "construction phase" for the segment foundation, much like an unsealed factory, during which data may be stored into the segment by "natural means". Upon sealing the segment becomes read-only. This could use an existing segment keeper or a new keeper.

We introduce a specialized injuction for "foundations", a new type of object. Foundation injuctions designate a foundation and "are against the destruction" of the foundation. FIs (foundation injunctions) are either valid or invalid. An invocation of the FI reveals which.

An order on the FI destroys that FI and produces a new one that designates the same foundation.

Thus I can transfer my authority over foundation F to you by sending you my key to my FI, whence you invoke this operation, whereafter you know that you have the injunction and I don't.

Holding an injunction for a foundation is worthless unless you trust others who hold keys to the same injunction -- thus the complete transfer, described above.

One need not trust foundation logic inorder to trust factory logic. The foundation may be viewed as merely a strange way to get a requestor's key to a factory.

One need not trust factory logic to be convinced of the durability promised by foundations. (??) This is not yet clear!

One source of change is the 370's TOD clock. I consider a compiler that fails beyond some data to be mutable. This is not a prlblem on most other machines.