Explanatory documentation only. These examples are non-normative Host integration sketches. They are not production code, a Demo Application, or a substitute for the frozen protocol and accepted Phase 7 specifications.
SecureToolKit sits between untrusted tool proposals and Host-owned side effects. The examples show how a Host can retain independent expectations, call only public controlled transitions, validate deterministically, and keep Consumption and Execution outside the library.
| Example | Focus |
|---|---|
| Basic Authorization | Phase 6 issuance and pure Validation of an exact request |
| Policy Evaluation | Deterministic evaluation against a published policy snapshot |
| Host Boundary | Genuine Host authority and boundary-identity continuity |
| Human Confirmation | The complete Phase 7 evidence path from Policy through Validation |
| Validation | Independently retained expectations and non-consuming Validation |
| Threat Model | Negative examples for mutation, replay, identity swap, boundary mismatch, and expiry |
Every guided example explains the problem and why its flow exists, then provides architecture and sequence diagrams, small Swift fragments, the expected lifecycle, threats prevented, common mistakes, and links back to the governing documentation. The detailed Phase 4–6 walkthroughs provide the same orientation around longer snippets.
- Start with Policy Evaluation to see why a model proposal is input—not authority.
- Read Host Boundary to understand where authority originates and why descriptive equality is insufficient.
- Follow Basic Authorization for Phase 6 issuance and Validation.
- Continue to Human Confirmation for the Phase 7 evidence lifecycle.
- Study Validation to retain expectations independently and preserve pure, repeatable Validation.
- Finish with Threat Model and exercise the negative paths before connecting any Host side effect.
The detailed historical walkthroughs remain available for Phase 4, Phase 5, and Phase 6.
The protocol documents are authoritative. These examples illustrate selected valid call sequences but do not define fields, equality, precedence, versions, limits, or failure semantics. If an example and an accepted or frozen protocol document differ, the protocol document governs and the example is defective.
Start with the Phase 1–6 protocol, the Phase 7 architecture, and the Phase 7 implementation contract.
Swift fragments use the public SecureToolKitCore API only. Names such as
retainedEvaluationInput represent Host-owned values prepared outside the
fragment; they do not imply hidden initializers or bypasses. Where construction
is controlled, examples use only the corresponding public transition.
The snippets deliberately omit adapters, persistence, networking, UI, cryptography, trusted clocks, replay stores, audit stores, and executors. A Host must supply those facilities where the protocol assigns them to the Host.
Use these guides as a navigation layer:
- README explains the project and trust boundary.
- Architecture defines component responsibilities.
- Security model and threat model define the security posture.
- Security invariants state the hard guarantees and Host obligations.
- API design explains the public API philosophy.
In every example, the Host means the application using SecureToolKit. Names
such as hostBoundary, retainedContext, and explicitValidationTime stand for
values that application owns and supplies; they are not ambient library state.
See the README responsibility matrix.
No example treats a model response, Policy allow, confirmation, Authorization, or successful Validation as permission to execute by itself. The Host must still perform the required durable atomic single-use Consumption before its own executor is invoked. SecureToolKit provides no executor and performs no Execution.