Every LEF Build is delivered this way: sealed inside the partner’s own confidential-compute environment. The partner receives the Build inside a trusted execution environment they choose, together with the work of fitting it to their records and operational environment.
🔒 Confidential-compute deployment, validated
The Secure Enclave deployment architecture is validated on GCP Confidential Space (AMD SEV) with hardware remote attestation. In plain terms: the deployment runs in a sealed container inside your environment, your data never leaves it, license/access is verified inside the enclave, and Living Eden Frameworks holds no remote kill switch, cannot reach into your environment, and cannot see your data. Other confidential-compute platforms (AWS Nitro Enclaves, Azure Confidential VMs) and GCP Assured Workloads, for a federal compliance boundary, are not yet tested.
Private Enclave Deployment
The Build deploys inside the partner's chosen Trusted Execution Environment; GCP Confidential Space is the one tested today. This includes enclave deployment, attestation-policy configuration, fitting the Build to the partner's records, and dedicated engineering through production deployment.
Fee structure
This Schedule defines the structure and cadence of the fee terms. The figures, and any exclusivity premium, are set in the Field License you sign, to your scope and field of use; they are not published here.
- Base Integration Fee (the one-time field-license fee in Field License §3.1), billed across three partner-verified milestones: container build; wiring to your records and test; and a period of sustained operation in your environment.
- Annual Access Fee (the flat annual fee in Field License §3.1), the only recurring charge besides an exclusivity premium where one is elected, set once at scoping from the data-complexity (or program-scope) tier, read from the corpus’s volume, field count and number of sources read together, and flat for the term. No separate maintenance fee and no revenue royalty.
- Warranty, for 90 days after acceptance: LEF corrects any defect in the build as delivered, at no charge, as a new image delivered the way the first was.
- Optional add-ons, each a new image or a change made at LEF, never the running of your deployment: a change-order hourly rate for the engineering that partner-side schema changes require, and, after the warranty, a monthly retainer under which LEF makes new images of your build at your request and delivers each as the first was delivered. Under neither does LEF operate, monitor or access your deployment.
Operational records stay with you
Each run writes its own operational record (the processing stage reached, any error classification, the run's duration and its complexity tier) inside your environment, where you hold it. Nothing is sent to LEF: the container opens no connection to LEF, and what leaves your environment is governed by your own network controls. If you choose, you can hand that record to LEF to help diagnose a failure.
Intellectual property
- Layer 1, LEF Substrate Architecture (non-negotiable): retained by Living Eden Frameworks LLC. The LEF substrate, engine architecture and the canonical-element graph remain LEF-owned: the patent-protected mechanisms describing how the engine works. No license is granted to the substrate itself.
- Layer 2, LEF SI.E (the meta-engine): retained by Living Eden Frameworks LLC. LEF SI.E is Engine Core and Verification, the code every build is made from, and the self-evolving application that operates the Layer 1 substrate across every LEF build. While Layer 1 describes the mechanisms, Layer 2 IS the running engine that executes them. At LEF it refines itself across runs and builds; inside your deployment it learns within each run, keeps what it learns between runs only where you give it a place to keep it, and nothing it learns returns to LEF. Proprietary application, trade-secret implementation, and self-evolution behavior. No license is granted to LEF SI.E beyond running the copy carried inside your Build, under the Field License.
- Forks and changes: any fork or change to the Build, made by either side, belongs to LEF unless otherwise agreed in a contract signed by LEF and the partner (Field License §6.2).
- Outputs: what the Build produces when run on your records, in your environment, is yours (Field License §6.3).
Pause, exit, and decommission
Access is payment-gated. If the Annual Access Fee is not paid, whether a missed payment or a deliberate pause between cycles, the Build runs through the grace period stated on its license token and then ceases operation (it stops running); it does not erase or destroy anything, and a later payment resumes the same deployment for a fresh full cycle with no re-onboarding. Living Eden Frameworks never reaches into your environment to remove or disable software.
On a true exit (not a pause), you decommission the Build within your own environment; where deployed in a TEE this is performed by cryptographic erasure. You may optionally file a machine-verifiable erasure attestation as a clean record of decommission, but none is required. The uncapped liability carve-out in the Field License (§7.4) attaches to operating the Build past its license token’s grace period by defeating or circumventing the token, or keeping it in operation after a true exit; never to a pause, and never to any attestation step.
Model use, on your own credentials if you elect it
The build runs as code and needs no model, and no model credentials, to produce its outputs. Where it offers an optional narration seat and you elect it in writing, that seat runs on your own account and credentials, for the model house you name from those LEF has benchmarked for that build, as listed in its handover. Model usage is billed by the provider directly to you; Living Eden Frameworks does not supply the key and does not resell, mark up, or meter model usage. The Annual Access Fee covers the build, not any model spend.
Why every build is delivered this way
Partner records do not leave the partner's environment, enclave deployment is what policy and procurement usually require, and the Build operates as internal infrastructure inside the partner's security boundary.
The License Schedule, completed per deal
The Field License sends each of these here. Each is written in for the named program when the license is signed.
- Named program or product line (Field License §2.2): [to be completed per deal]
- Exclusivity within the program (§2.4): elected / not elected; if elected, the annual exclusivity premium (§3.1): [to be completed per deal]
- The LEF filings that protect the licensed Build (§6.4): [to be completed per deal]
- Any agreement on forks or changes (§6.2), by reference to the signed contract: [none, or the contract named]
- Any agreement to modify or automate the Build for the program (§7.3): [none, or the agreement stated]
- Optional narration seat (§4.1): not elected / elected, with the model house named from those benchmarked for this Build: [to be completed per deal]
- License token term and grace period (§9.1): [to be completed per deal]
This Schedule attaches to a Field License.