# Licet learning hub: curriculum and technical specification Edition 1.1 · 10 October 2026 · /learn/ This specification describes the learning product, the inspected research-prototype interface, and proposed integration acceptance criteria. It is not a standard, certification, legal opinion, agency authorization, or a production conformance claim. ## Purpose and audience Enable a learner to explain how institutional authority becomes bounded permission, inspect what a record proves, and plan a responsible integration. General counsel, federal authorizing officials, cybersecurity specialists, and developers share the same foundation but receive different professional questions. An enterprise leader can follow the common path to understand accountable delegation and the measurable adoption hypothesis. The primary outcome is transfer: can the learner analyze a new automation scenario without confusing a credential, institutional permission, signature integrity, gate decision, and actual execution? ## Learning architecture Eight modules form a dependency sequence: purpose; authority chain; boundary; integration; evidence; failures/change; adoption; capstone. The role paths prioritize relevant modules but keep all modules accessible. Each module includes an objective, short conceptual explanation, a fictional worked example, a professional lens, private self-explanation, a retrieval check with corrective feedback, and a subsequent step. The lab introduces variable scope, action, approval, and status. Learners predict before receiving a verdict and causal explanation. This is a deterministic browser teaching model, not a connection to the actual runtime gate. The closure-specific approval profile is illustrative and richer than the inspected minimal gate request. The lexicon pairs a definition with a misconception boundary. The technical reference exposes concrete implementation seams and failure obligations. Progressive disclosure keeps dense details available without making them prerequisites to the introductory path. ### Evidence-informed pedagogy Use worked examples before independent transfer, active retrieval rather than passive rereading alone, explanatory feedback, self-explanation, contrasting cases, and delayed recall. Research references are listed below. A 2025 review reports context-dependent benefits for retrieval; a 2025 worked-example study motivates predict-then-reveal sequencing. Neither study validates this professional curriculum. Avoid learning-style typologies, decorative point systems, and claims that completion demonstrates competence. Recall review is available after 1, 3, and 7 days following successful checks. These intervals are a design choice. The browser shows due reviews on return; no notification or scheduled task is created. Repeating a check before it is due does not keep postponing its due date. ### Proposed evaluation protocol Recruit separate novice and experienced participants across the four roles. Use an alternate-form pretest, immediate transfer task, and delayed recall/transfer tasks. Score distinctions and reasoning on unseen support, purchasing, and infrastructure cases. Compare to a matched static explanation where feasible; predefine scoring rubrics, timing, exclusion criteria, and meaningful outcomes. Measure misconceptions, task completion, accessibility failures, and time-on-task alongside accuracy. Do not collect participant data through this shipped hub. Formal study participation and data collection require a separately designed research process. ### Proficiency rubric 1. Distinguishes capability from permission and permission from execution. 2. Traces a condition through source, applicability, interpretation, policy, control, evidence, approval, and change. 3. Names the execution seam and identifies possible bypass routes. 4. Explains signature/key/identity/factual-support limits. 5. Handles stale, absent, contradictory, and not-assessed information without turning it into a pass. 6. Transfers the model to an unfamiliar workflow and assigns evidence requests with confirmed ownership. The hub's progress indicator records correct recognition checks only. It does not assess this full rubric or issue credentials. ## Product truth boundaries Licet's governing direction is to turn obligations into accountable operating decisions supported by evidence and maintained as systems change. The inspected foundation implements signed, versioned authorization records, authored-rule derivation, approval readiness, lifecycle/revalidation context, gate decisions, a reference runtime client, and independent integrity verification. The public site is a separate marketing and learning service, not the production application. Structured applicability review, richer interpretation disagreement workflows, comprehensive agent profiles, production identity/executor integration, operational effectiveness assessment, and claims substantiation must not be implied complete because a learning example describes them. Work in other branches or worktrees is not treated as released functionality. Authorization does not establish legal compliance, control effectiveness, certification, or transfer of institutional duties. A verified signature does not establish trusted human identity or source truth. A collection specification is not collected evidence. Missing logs do not establish absence of incidents. Contrary evidence and original versions remain part of the record. ## Existing prototype interface Base path: `/api/v1/licet`. The public learning site does not host this API. Officer-authenticated application routes govern access; production identity configuration is outside this tutorial. ### Gate request `POST /api/v1/licet/contracts/{contract_id}/gate` ```json { "tool": "YOUR_REGISTERED_TOOL", "data_domain": "YOUR_MODELED_DOMAIN", "target": "YOUR_TARGET" } ``` `tool`: required string. `data_domain` and `target`: optional strings. Names are placeholders, not provisioned permissions. The fields do not constitute an arbitrary rich agent-policy schema; do not assume spending limits or exact-action approval tokens can be added and enforced. ### Response The inspected `_gate_response` returns: - `decision_ref`: recorded evaluation reference. - `contract_id`, `contract_version`, `canonical_digest`: evaluated record identity. - `lifecycle_state`: evaluated lifecycle state. - `boundary_id`, `boundary_version`, `system_name`: bounded system context. - `call`: echoed `tool`, `data_domain`, `target`. - `registry_status`: revalidation context. - `decision`: verdict (`ALLOW` or `DENY`), basis, headline, citations, remedy. - `elapsed_micros`: pure gate computation duration; excludes network/database/adapter latency. The shared response path commits the gate decision before returning it. Both POST and GET forms use it; the GET form therefore has a logging side effect. The POST route's older read-only docstring is not used as the behavioral authority here; the implemented shared path is the basis for this explanation. An ALLOW is not execution. The API itself is not the tool's enforcement point. ### Payload and signatures `AuthorizationContract` includes schema version, contract ID/version, boundary ID/version/digest, conditions, issued/expiry dates, reauthorization triggers, default violation/lapse behavior, interpretation-pack/corpus bindings, policy-pack digest, future-applicability entries, approval rule, issuer, signature basis, and demonstration-content flag. The canonical payload does not simply contain all approvals and state history: approval attestations and lifecycle transitions have their own signed binding behavior. Canonicalization and digest checks establish the exact subject. Signature checking, issuer trust, registered holder attribution, authorization-readiness evaluation, reproducibility under pinned semantics, and factual support are separate steps. A legacy/unpinned record may be verifiable but not reproducible rather than silently treated as fully established. ### Reference client `runtime_client.py` validates service responses, rejects malformed or mismatched responses, verifies snapshots before cache admission, and rechecks cached integrity on use. On transport failure it decides from an admitted snapshot where policy permits; otherwise it denies. The inspected implementation has a two-second total deadline and a 256 KiB response bound. These are configured limits, not benchmarked production service guarantees. A signed registry checkpoint bounds offline validity. The inspected checkpoint policy is seven days, capped by record expiry when earlier. A cached status can miss a revocation after checkpoint issuance. Institutions must choose and test an appropriate freshness policy; shorter windows or denial during outages may be necessary. Never extend signed validity by assigning a later local fetch time. ## Proposed ecosystem integration contract The integration adapter must be at a tool executor, service gateway, or another non-bypassable side-effect boundary. The orchestrator retains planning, IAM retains authentication and technical permissions, the policy engine retains its supported evaluation role, and observability systems retain collection. Licet contributes institutional reasoning, bounded authorization, and version-linked evaluation references. The adapter must: 1. Resolve principal, agent, tool, resource, and context from trusted sources. 2. Normalize the actual call into supported structured vocabulary. 3. Select the governing version/status and evaluate permission. 4. Validate the response schema, known verdict, echoed call, record digest/version, and freshness basis. 5. Deny when the required permission basis is absent or invalid; never allow solely because a transport error was caught. 6. Prevent request substitution between evaluation and execution; re-evaluate changed actions. 7. Execute only the permitted actual proposal. 8. Retain an independently sourced execution outcome linked to the decision reference, including failure/partial outcome. 9. Reconcile actions with decisions over a defined deployment and observation period. 10. Detect unsupported semantics, stale state, bypass paths, and collection failure explicitly. This is an engineering contract to validate, not an available production SDK. Rich exact-action approvals, delegation profiles, and arbitrary resource/amount checks require structured semantics and executor bindings appropriate to the deployment. A prose condition is not advertised as enforced without that binding. ## Threat model and enterprise acceptance Threats include prompt injection driving out-of-scope calls; forged or stale artifacts; compromised keys; confused-deputy credentials; child authority expansion; time-of-check/time-of-use substitution; alternate endpoints; incomplete or agent-authored telemetry; semantic pack drift; outage/revocation delay; and a disabled or bypassed gate. An authorization record cannot alone remove these threats. Before claiming protection, obtain identity and key-custody evidence, tenant isolation tests, inventory of side-effect routes, request-mapping tests, negative bypass/replay tests, containment checks, expiry/revocation/outage tests, journal and collector failure behavior, evidence completeness/reconciliation, and independent scope review. Define observation windows and denominators. The product-value hypothesis is reduced repeated review and easier reconstruction of why a system may act. A pilot must measure review effort, valid actions denied, exception workload, missing/contradictory receipts, bypass findings, revocation delay, and end-to-end latency against a baseline. No universal ROI, zero-friction, or compliance guarantee is asserted. ## Federal authorization context NIST SP 800-37 Rev. 2 provides the RMF lifecycle framework. Licet may be evaluated as a proposed structured source of requirements, decision rationale, permission constraints, and evidence references within an agency's process. It is not an ATO, an authorizing official, a FedRAMP authorization, or a replacement for system security/privacy plans, control assessments, POA&Ms, monitoring, or agency risk decisions. Mapping a concept to RMF does not establish conformance. Agency-specific roles, inherited controls, boundary definitions, and acceptance criteria govern. NIST AI RMF is voluntary guidance; the AI Agent Standards Initiative is relevant context for identity/interoperability/security work. Neither constitutes endorsement of Licet. ## Delivery and maintenance Route: `/learn/`, with a permanent slash redirect supplied by the existing static-asset routing behavior. Hash-addressed views and lessons are directly linkable. No account, AI service, external integration, or data store is needed. Static JS/CSS assets are embedded by the existing Worker build. Progress stores only lesson pass state, stage, and recall due timestamp in `localStorage` under `licet-learn-v1`. Reflection text is transient and not persisted. Reset removes effective progress. Storage denial must not break learning. Third-party fonts are presentational; fallbacks remain readable. No analytics or participant-data collection is added. Accessibility: semantic landmarks and headings, keyboard buttons/links, visible focus, labeled fields, live feedback, no color-only verdicts, reduced-motion treatment, responsive single-column layout, and horizontal scroll for wide code/tables. Formal WCAG assessment is not claimed. Maintenance: update source `public/learn/content.js`, `public/learn/learn.js`, `public/learn/style.css`, `public/learn/index.html`, and this specification. `build-learning-spec.mjs` generates the downloadable complete curriculum. The site build runs it so downloads stay aligned. Review content after material API, authority-pack, lifecycle, or product-status changes. Preserve explicit shipped/planned distinctions; append a learning-edition change log when semantics change. ## Source provenance Application checkout base revision: `bb041f8683f8a66500299633dfaa6daf5b897789`. Pre-existing working-tree modifications are not represented by that commit alone; the inspected file behavior, rather than a release claim, governs this explanation. Inspected source paths in the shared Licet repository: - `docs/product-direction.md` - `docs/PRODUCT-STATUS.md` (historical September status, not treated as a current production release claim) - `docs/authorization-layer-design-grammar.md` - `docs/examples/agent-authorization-case.md` - `src/licet/contract/boundary.py` - `src/licet/contract/contract.py` - `src/licet/api/v1/contracts.py` (`GateRequest`, `_gate_response`, gate routes) - `src/licet/runtime.py` - `src/licet/runtime_client.py` - `src/licet/checkpoint.py` The shared application checkout has pre-existing uncommitted changes and parallel development. This tutorial describes the inspected files, not a claim that all branch work is deployed. The marketing Site’s source revision is recorded by its deployment; the learning hub is independently versioned as edition 1.0. ## Edition 1.1 experience update The home experience adds three fictional decision stories (support, purchasing, infrastructure), with selectable capability, permission, and evidence stages. The visual layer uses translucent glass surfaces, readable opaque fallbacks, a sticky header/navigation and lesson steps, and a persistent progress/continue control. Dense lesson views hide the introductory hero to keep the current task in focus. Scenario selection is transient. Keyboard focus is preserved after scenario changes and motion/transparency preferences are respected. The existing tutorial, evidence boundaries, knowledge checks, and browser-local progress remain the source of learning semantics. ## Progressive-enhancement correction — 11 October 2026 The build emits static summaries of all eight lessons, role guidance, a worked decision case, the lexicon, technical overview, and sources into the HTML. Navigation anchors target content sections, not navigation links. Perspective links exist before script execution; successful initialization replaces them with interactive buttons. The basic reading path does not require JavaScript or the engineering specification. Mobile navigation uses full-height tap targets without an overlapping scrollbar. Essential static-content invariants are checked in the publication content checks. ## Role-adapted learning Each of the eight lessons has authored general counsel, authorizing official, cybersecurity, and developer variants for its title, opening, objective, and fictional worked example. The conceptual sections and knowledge checks remain shared. Selecting a role on the home opens its first lesson; switching within a lesson preserves the topic and replaces the professional framing immediately. Previous and next navigation follow the selected role’s recommended path. ## Visual learning studio All eight enhanced lessons now lead with an inspectable authority diagram and a browser-local mission: artifact classification, sequence assembly, scope selection, enforcement placement, evidence bundling, freshness timeline, pilot design, and changed-tool incident review. Common explanatory sections remain expandable. Role-specific objectives and cases are retained. Feedback identifies incomplete or overclaiming reasoning and allows revision; completion uses the existing local recall schedule. Shared completion reflects practice, not competence certification. The static eight-lesson fallback remains intact. ## Continuous case and authentic professional workspaces Meridian Support is a five-chapter fictional case. First-attempt mandate judgments are recorded independently from revisable practice. Legal learners inspect policy editions and attributed interpretation; federal learners assess boundary and missing assessment material; security learners exercise a direct-worker bypass; developers inspect mismatched request/receipt artifacts and assemble a validation seam. A new bulk-close worker and authenticated revocation introduce a changed decision. Submitted responses generate deterministic fictional consequences; uncommitted drafts do not alter outcomes. The journal retains earlier decisions. Recommitting the incident clears later evidence findings and resolution to avoid stale conclusions. An unfamiliar purchasing, infrastructure or data-operations case measures five structured concepts without hints before submission. Rationale grading requires explicit learner or facilitator review against four criteria; no AI/prose grader is connected. First attempts, practice retries and delayed recall are separated. Delayed practice unlocks after 24 hours and uses a different scenario from the latest transfer attempt. The separately downloadable learning-validation.md defines a proposed comparative evaluation and limits on interpreting formative scores. No participant study, telemetry or remote result collection is implemented. All learning state and local exports are distinct from actual authorization records, production evidence, compliance findings and agency decisions. # Complete curriculum ## Lesson 1: Why an authorization layer? Objective: Separate capability, permission, and proof of execution. An agent can call a tool. That does not answer who permitted the action, within which limits, or what evidence shows it stayed there. ### The organizational problem Across a large enterprise, legal requirements, internal policy, approvals, technical controls, and execution logs often live in separate systems. When an agent changes a customer account, the institution needs to reconstruct a specific chain: what applied, what it decided, what it permitted, what actually happened, and what would require a new decision. ### What Licet contributes Licet’s working prototype derives conditions from a bounded system description and authored rule/interpretation packs. It records institutional permission in a signed, versioned authorization record. Gate decisions can cite the conditions and reasoning behind a particular allow or deny. Production identity, executor integration, and operational assurance need their own validation. ### Why an entity would use it The proposed value is a reusable institutional decision record: explicit ownership, consistent permission boundaries, visible uncertainty, and reviewable change history. Legal, engineering, security, and executives can refer to the same version rather than reconcile four incompatible summaries. Whether this reduces review time or incidents must be measured in a pilot. ### Where protection comes from A bounded permission can limit an agent’s blast radius when every execution path enforces it. Versioned reasoning supports investigation and change review. Neither a record nor a signature prevents prompt injection, eliminates legal liability, or proves that a bypass route does not exist. Protection depends on trustworthy identity, complete mediation, sound rules, and reliable evidence. ### Worked example (fictional) A support agent may investigate an assigned case and propose a closure. Having an account.close credential is technical capability. The institution may still require a separate human to approve the exact closure. An ALLOW means a checked action is permitted; a service receipt is needed to show it ran. ### Audience lenses - **General counsel:** Ask: what is the basis for permission, which duty is mandatory, and who owns unresolved interpretation? The record supports accountable review; it does not transfer the institution’s duties. - **Authorizing official:** Ask: what material does this contribute to the agency’s risk decision? Licet is not an ATO, a FedRAMP authorization, or an authorized replacement for an agency RMF process. - **Cybersecurity:** Ask: which tool paths can perform the action, and where is permission enforced? A control that misses a legacy endpoint cannot support an all-actions claim. - **Developer:** Ask: can a call reach the side effect without the gate? The enforcement seam belongs before execution, not in an agent’s prompt. ### Retrieval and explanation The record is signed and the gate returned ALLOW. What can you conclude? 1. The action is compliant and was successfully executed. 2. The evaluated action was permitted under the checked record; execution still needs evidence. 3. The model is safe for all future tasks. Answer: 2. Permission, execution, and compliance are separate claims. An ALLOW is not an execution receipt and a signature is not a safety assessment. Self-explanation: Explain to a colleague why a tool credential and an institutional authorization answer different questions. ## Lesson 2: Trace the authority chain Objective: Follow one condition from source to revalidation. The record is useful because you can follow the reasoning—not just see that someone approved it. ### 1. Source and applicability Identify the exact law, contractual commitment, standard, or internal policy and its edition. Decide why it applies to this system, jurisdiction, population, and date. A voluntary framework is not automatically a binding legal duty. Structured applicability decisions are part of the product direction; a citation alone is insufficient. ### 2. Interpretation and policy An institution explains what a requirement means here, with attributed judgment. It then expresses an operating policy. Preserve rationale and uncertainty; a model may suggest language, but cannot create legal authority or accept residual risk. More formal alternatives and disagreement workflows remain planned. ### 3. Control and evidence Translate the policy into a condition, specify a control, and state evidence to collect. An evidence obligation is an instruction. A collection specification is a method. A successful query, a test result, and an independently assessed finding are different artifacts. ### 4. Approval and maintenance Required approvals are evaluated under the institution’s policy pack. A record binds the boundary and semantic packs by digest. Violation behavior states the response to a breached condition; revalidation triggers identify changes that require another decision. The signed history should preserve the original decision rather than overwrite it. ### Worked example (fictional) Fictional company policy requires review before account closure. Interpretation: review must precede the action and bind to its exact digest. Control: the closure executor rejects absent, expired, or mismatched approvals. Evidence: approval records, executor receipts, replay tests, and reconciliation over a defined period. Change trigger: a new bulk-close endpoint. ### Audience lenses - **General counsel:** Inspect whether an institutional choice is being presented as a statutory command. Record assumptions, the interpreter, relevant date, and contrary information. - **Authorizing official:** Map the contribution to applicable agency artifacts: requirements, control implementation, assessment results, residual risk, and the accountable official’s decision. This is a conceptual crosswalk, not equivalence. - **Cybersecurity:** Translate each condition into an observable failure and a test. Ask who assesses the evidence and whether the evaluated agent can fabricate it. - **Developer:** For each prose condition, name the typed field and code path that enforce it. If none exists, label the condition documented rather than enforced. ### Retrieval and explanation A record says “collect an execution receipt for every closure.” What does this establish? 1. Receipts were collected for every closure. 2. The obligation to collect receipts is documented. 3. All closure controls passed. Answer: 2. A requirement is not a result. Actual receipts, completeness checks, and an assessment period are needed to support an operational claim. Self-explanation: Pick a policy you know. Identify its source, interpretation, control, evidence, and change trigger. ## Lesson 3: Define the operating boundary Objective: Describe scope and identify a scope expansion. Authorize a bounded system, not an unlimited promise that an agent will behave well. ### Start with the system The prototype boundary describes the system and capabilities that conditions are derived against. A useful real deployment profile also needs principal and agent identity, action and resource scope, data access and egress, tool/model versions, consequential human approval, delegation limits, expiry, and failure handling. Richer agent profiles are a design requirement, not a blanket claim of enforcement. ### Keep delegation contained A child agent must not gain authority its parent does not hold. A task instruction such as “resolve this case” cannot expand a structured permission. Delegation lineage, typed scope, and containment must be checked against the governing artifacts and policy profile. ### Distinguish description from enforcement “Use good judgment” and “for customer support” describe intent. They are not executable constraints by themselves. A real integration must bind supported structured conditions to actual tool arguments and resources. Unknown or unsupported conditions need explicit handling; silently treating them as satisfied would remove the boundary. ### Change the envelope deliberately Expanding jurisdictions, tools, resources, or autonomous actions can change what applies and what risk is accepted. Preserve the old version, derive or review a successor, and obtain the required approvals. Whether a particular configuration change fits within a preauthorized envelope depends on a validated profile. ### Worked example (fictional) The parent can read case 42 and draft a recommendation. A child that requests account closure is asking for a new capability, not merely a new way to finish the same task. Its authority cannot be inferred from the parent’s natural-language goal. ### Audience lenses - **General counsel:** Look for permitted outcomes, prohibited actions, populations, jurisdiction, expiry, and who can approve expansion. Purpose labels alone do not constrain execution. - **Authorizing official:** Align the system scope with the actual authorization boundary and inherited services. Dependencies and changed interconnections need the agency’s own impact analysis. - **Cybersecurity:** Define identities and resources at the enforcement point. Check confused-deputy behavior, delegated credentials, alternate endpoints, and data egress. - **Developer:** Validate the actual tool and arguments after planning and before execution. A changed action should not reuse approval of an earlier action. ### Retrieval and explanation A delegated agent asks for a permission outside its parent’s scope. What is the sound response? 1. Allow it because it supports the same goal. 2. Let the agent describe why it needs access. 3. Refuse the expansion and route it through the appropriate authorization review. Answer: 3. A shared goal does not establish authority. Delegation must preserve containment; any expansion needs its own authorized decision. Self-explanation: Name one descriptive field and one enforceable field in your own agent design. ## Lesson 4: Fit Licet into your ecosystem Objective: Place the check before the side effect and bind the resulting evidence. Your orchestrator still plans. Your identity platform still identifies. Your executor still acts. The authorization layer connects permission to a particular action. ### The integration seam Use an adapter at the tool executor, API gateway, or other point that can actually stop the side effect. Resolve identity and context; normalize the proposed tool call; evaluate the governing authorization; validate the response; execute only the permitted action; then retain the execution outcome. Framework-specific integrations require engineering and testing. ### What stays in your stack IAM authenticates and supplies technical access. Policy engines can evaluate compiled rules. GRC systems track controls and assessments. SIEM and observability platforms collect events. Licet’s proposed contribution is the versioned institutional reasoning and permission record that connects these systems. It does not replace IAM, a firewall, EDR, model evaluation, or the tool executor. ### The API that exists The inspected prototype exposes POST /api/v1/licet/contracts/{contract_id}/gate with tool, optional data_domain, and optional target. The response includes record identity, a decision reference, lifecycle and registry context, and a nested decision. The route records a decision before returning it. It is an authorization evaluation API, not execution of the tool. ### What the adapter must validate Treat a successful HTTP status as transport success only. Validate types, known verdict vocabulary, the echoed call, the record version and digest, and failure behavior. Do not insert illustrative amounts or human-approval tokens into this minimal API and assume they are enforced: those require a profile and executor binding beyond its current request shape. ### Worked example (fictional) Your tool wrapper receives a request, obtains a validated permission decision, and calls the service only if the verdict is ALLOW. It attaches the decision reference to a separate execution receipt. If the request changes before execution, it evaluates again. This is a proposed integration pattern, not a drop-in production SDK. ### Audience lenses - **General counsel:** Ask engineers to demonstrate a denied side effect and the trace back to the institutional condition. A diagram alone is not control evidence. - **Authorizing official:** Identify where the enforcement component sits in the authorized system and how its failures, keys, logs, and dependencies are assessed. - **Cybersecurity:** Prefer a narrow, non-bypassable execution seam. Decide who can edit the adapter and policy, and detect paths that avoid it. - **Developer:** Start with one tool and deterministic request mapping. Measure adapter latency and error paths. The service’s elapsed_micros times its pure gate, not the whole network call. ### Retrieval and explanation Where should permission be checked? 1. Only in the system prompt. 2. At a point that can stop the actual side effect. 3. Only after the agent has finished. Answer: 2. Prompts influence behavior but cannot guarantee complete mediation. The execution point must enforce the decision before the action becomes real. Self-explanation: Sketch the single tool wrapper you would integrate first. Identify each route that could bypass it. ## Lesson 5: Read evidence without overclaiming Objective: State what an artifact proves and what it leaves unknown. A strong evidence culture makes “not assessed” visible. It does not turn missing information into a green badge. ### The integrity claim A digest identifies exact content. A valid signature links those bytes to a key. Trust in the key issuer and attribution to a real authorized person require separate evidence. The public demonstration uses demonstration keys and fictional reviewers; successful verification does not make them real. ### The permission claim Institutional authorization means the institution’s required permission process was satisfied for a bounded version. It does not establish implementation, effectiveness, compliance, certification, or current runtime behavior. Risk acceptance cannot silently waive a mandatory duty or override a prohibition. ### The operational claim To say a control operated, define the deployment, period, method, denominator, collector, reviewer, freshness, and limitations. Use independently sourced observations where the claim needs them. A gate receipt documents an evaluation; an execution receipt documents a reported action. Reconciliation connects them and detects missing or contradictory records. ### The contrary-evidence test Suppose 999 closures have matching approvals and one bulk-close endpoint bypassed review. Preserve the failure and narrow the claim. A later passing test does not rewrite the earlier observation period. Separate missing, stale, conflicting, failed, insufficient, and not-assessed states. ### Worked example (fictional) Claim: every closure in deployment X during week Y had valid prior approval. Evidence needed: a complete execution inventory, approval records bound to actions, time ordering, endpoint coverage, reconciliation, and reviewer findings. “The record contains seven links” does not establish that claim. ### Audience lenses - **General counsel:** Ask what the organization can substantiate, not what a complete-looking chain implies. Preserve contradictory evidence and uncertainty. - **Authorizing official:** Assessment results and the official’s risk decision remain distinct. Evidence supplied to an authorization package must have appropriate provenance and scope. - **Cybersecurity:** Test collector tampering and missing-event detection. An evaluated agent’s own assertion is not independent evidence of its behavior. - **Developer:** Keep decision and execution identifiers together without calling ALLOW “executed.” Capture failures and partial results as well as success. ### Retrieval and explanation A signature verifies against a copied demo key set. What does that check support? 1. Real-world approver identity and legal authority. 2. Integrity of the signed bytes against those keys, with key-trust limits. 3. Current revocation status and control effectiveness. Answer: 2. Signature verification establishes a cryptographic relationship. Issuer trust, real identity, current status, and control effectiveness require distinct checks. Self-explanation: Complete the sentence: “This artifact supports ___, but it does not establish ___.” ## Lesson 6: Handle outages and change Objective: Explain fail-closed behavior and the limit of offline authorization. An enforcement point still has to decide when the registry cannot answer. That decision needs a defined freshness policy. ### The reference client The inspected reference client validates responses and uses a verified cached snapshot when fresh service evaluation fails. Without an admissible snapshot, it denies. Snapshot verification binds the record, boundary, lifecycle history, and registry checkpoint. A dictionary labeled “verified” is not an admitted snapshot. ### The offline tradeoff The prototype checkpoint uses a seven-day maximum offline window, bounded by the record’s expiry if earlier. A cached authorization cannot see a revocation after its checkpoint. Production deployments must choose and justify their own policy; high-consequence actions may require a shorter window or denial during an outage. Offline continuity and instant revocation cannot both be guaranteed. ### Budget and observability The reference HTTP client has a two-second total timeout budget and a 256 KiB response bound. These are implementation limits, not a measured production SLA. Measure end-to-end latency, cache age, denials, transport failures, and journal health in the actual integration. ### Triggers create new decisions A changed authority edition, policy interpretation, tool path, model behavior, or control failure can require revalidation. Keep the exact old record and the new assessment distinct. A superseding version should not silently alter the reasoning or signatures on its predecessor. ### Worked example (fictional) The registry becomes unreachable. No verified cache: deny. A valid verified snapshot: decide within its signed freshness bound and disclose that basis. A stale snapshot: deny. A later revocation may remain unseen during the admitted offline window. ### Audience lenses - **General counsel:** Agree which failures require a stop, who can accept residual risk, and whether any mandatory obligation prevents a grace period. - **Authorizing official:** Coordinate freshness and outage behavior with agency risk tolerance and continuous monitoring. A cached prototype decision is not ongoing authorization under RMF. - **Cybersecurity:** Exercise revocation during an outage, stale replay, corrupt snapshot, unregistered key, journal failure, and clock skew. - **Developer:** Use the verified snapshot admission path and validate the complete response. Never let catch(error) become allow(). ### Retrieval and explanation Can a valid cached snapshot guarantee immediate recognition of a later revocation? 1. Yes, because it is signed. 2. Yes, if the agent is confident. 3. No; its status knowledge is bounded by checkpoint freshness. Answer: 3. A signature cannot reveal a future event. Offline evaluation has a revocation-delay tradeoff that the deployment must explicitly govern. Self-explanation: Choose an outage policy for a low-impact read and a consequential account closure. Explain why they differ. ## Lesson 7: Reduce friction by design Objective: Design a pilot that tests both protection and workflow cost. The goal is useful autonomy within a reviewed boundary. Less friction is a hypothesis to validate, not a reason to weaken the boundary. ### Predefine the ordinary path A proposed deployment pattern is to authorize a narrow routine capability, place a deterministic check at execution, and escalate scope changes or consequential exceptions. This avoids asking a lawyer to review each ordinary tool call while retaining institutional accountability. Richer preauthorized envelopes need validated semantics and an integration that enforces them. ### Reuse the reasoning A reviewed interpretation and policy can inform multiple systems when it applies to each. Reuse must preserve versions, applicability, and system-specific risk. Changing a shared pack should make affected authorizations identifiable; it should not silently reinterpret historical records. ### Start in observation Begin with a single reversible tool and a documented risk owner. Inventory routes, compare candidate decisions with independently captured actions, and investigate disagreement. Shadow mode helps characterize behavior but cannot prevent the observed action. Moving to enforcement requires tested coverage and a reviewed failure policy. ### Measure the enterprise value Compare review effort, time to reconstruct a decision, exception rates, denied valid actions, bypass findings, missing receipts, revocation delay, and end-to-end latency against a defined baseline. Use denominators and observation periods. Do not claim universal ROI, zero friction, or enterprise protection from a synthetic demonstration. ### Worked example (fictional) A pilot authorizes reading assigned support cases, with closure outside scope. Ordinary reads follow the routine path. A closure request creates an explicit review event. The team measures false denials, missing receipts, and review effort before deciding whether to broaden the boundary. ### Audience lenses - **General counsel:** Use a narrow claims register for the pilot: what was measured, over which scope, and with what limitations. Avoid promising immunity or compliance. - **Authorizing official:** Plan a scoped evaluation within the institution’s existing lifecycle and change process. Agency approval criteria govern any deployment decision. - **Cybersecurity:** An observation phase does not contain an attacker. Validate the actual stop path and adversarial bypass tests before enforcement. - **Developer:** Adopt one adapter before adding many. Expose denial reasons and actionable remedies so developers do not work around an opaque gate. ### Retrieval and explanation What supports a claim that Licet reduces review friction? 1. A polished demo and a short tutorial. 2. Measured review effort and error rates against a scoped baseline. 3. The number of signed records. Answer: 2. Operational value requires measured outcomes. A pilot should test workflow cost and control coverage together. Self-explanation: Define one benefit metric and one protection metric, including their baseline and denominator. ## Lesson 8: Put the whole chain to work Objective: Apply the model to a changed execution path and define the next decision. A new bulk-close tool appears after a support agent’s boundary was reviewed. The existing record permits investigation and recommendations only. ### Before deciding Inventory the new tool, actual caller identity, resources, data flows, and side effects. Read the exact governing boundary and record. Find the applicability basis and institutional interpretation. Determine whether closure is permitted and who can approve a changed scope. ### The sound immediate response Keep the unapproved closure capability outside the ordinary path. The appropriate risk owners review the expansion and required controls. A credential that can invoke bulk-close does not make it institutionally authorized. A proposed gate rule also does not establish that every route enforces it. ### Build the assurance argument For a proposed closure permission, require human approval bound to the exact action, child-scope containment, complete executor coverage, expiry/replay handling, and explicit outage behavior. Collect independent execution receipts, approvals, and reconciliation evidence over a stated period. These are proposed controls for this fictional case. ### The transfer task Now apply the same questions to a different workflow: a purchasing agent drafting an order versus committing spend. Do not copy the support policy blindly. Identify the source of spending authority, typed constraints, approval role, execution seam, evidence, and change triggers for that institution. ### Worked example (fictional) A defensible next step is an assigned evidence request: Engineering inventories and tests all closure endpoints; Legal/Policy confirms the interpretation and reviewer authority; Security assesses identity, bypass, and failure behavior; the accountable decision-maker reviews the bounded proposal and residual risk. Ownership must be confirmed, not guessed. ### Audience lenses - **General counsel:** Deliver an attributed interpretation with assumptions, alternatives, and an evidence request. Do not equate an internal approval with a legal opinion. - **Authorizing official:** Deliver the scoped contribution to the agency’s authorization package and identify missing assessment material. The actual authorizing official retains the decision. - **Cybersecurity:** Deliver a threat-focused test plan with endpoint inventory, bypass/replay cases, evidence completeness, and failure handling. - **Developer:** Deliver a proposed adapter contract, request mapping, fail-closed cases, version binding, execution receipt design, and measured latency plan. ### Retrieval and explanation The new bulk-close tool uses the same model and vendor as before. Is the old permission enough? 1. Yes; model and vendor are unchanged. 2. No; the changed capability and execution path need scoped review. 3. Yes; a high-confidence model can decide. Answer: 2. A system’s scope is more than its model. New side effects and routes can change authority, risk, and control coverage. Self-explanation: Write a five-line review: what applies; why; what is permitted; evidence needed; what triggers a different decision. # Lexicon ## Authorization Institutional permission for a bounded system/version under a defined approval rule. Distinction: Not a legal compliance finding or proof of execution. ## Boundary The system description and scope against which conditions are derived. Distinction: A purpose statement alone is not an enforced permission. ## Operating envelope The proposed set of actions, resources, identities, versions, and limits within which autonomy is permitted. Distinction: Richer profiles need validated enforcement bindings. ## Authority A source of requirements: law, regulation, contract, standard, or internal policy. Distinction: Their binding force differs; applicability needs a basis. ## Applicability The decision that a requirement matters to this system in this context and time. Distinction: A citation is not itself an applicability decision. ## Interpretation Attributed institutional judgment about what a requirement means here. Distinction: AI drafting cannot create authority or accept risk. ## Policy pack Institutional rules that determine authorization roles and approval readiness. Distinction: Different from the corpus that derives conditions. ## Corpus Authored authority editions, rules, and interpretations used in derivation. Distinction: Not an exhaustive legal analysis of arbitrary prose. ## Condition A derived operating requirement connected to the authority chain. Distinction: Documentation does not prove implementation. ## Control A mechanism intended to satisfy a condition. Distinction: It needs implementation and effectiveness evidence. ## Evidence obligation A statement of what should be collected to support a condition. Distinction: Not evidence already collected. ## Collection specification Instructions for how evidence should be obtained. Distinction: Not a successful collection result. ## Risk acceptance An accountable decision by a role authorized under institutional policy. Distinction: Cannot silently waive a mandatory duty or prohibition. ## Digest A content hash identifying exact canonical bytes. Distinction: A hash alone does not establish truth or trusted identity. ## Signature Cryptographic evidence that a key signed specified bytes. Distinction: Key trust and human attribution need separate checks. ## Canonicalization A deterministic representation used for signing and hashing. Distinction: Visually identical text may differ at the byte level. ## Registry A source of version, lifecycle, and revalidation context for authorizations. Distinction: A public record snapshot is not a live registry response. ## Checkpoint Signed registry status and freshness information bound to a snapshot. Distinction: Cannot reveal a revocation occurring after it was issued. ## Gate An evaluator returning a permission verdict and its basis for a proposed action. Distinction: The service evaluator does not execute or physically stop a tool. ## Enforcement point The component that can stop an actual side effect using the decision. Distinction: A prompt instruction is not a non-bypassable enforcement point. ## Decision receipt A record of evaluation for an exact request and authorization version. Distinction: ALLOW does not mean executed. ## Execution receipt Evidence of an action reported by the executing system. Distinction: Its provenance and completeness still need assessment. ## Revalidation Review required by a change, failure, or uncertainty affecting authorization. Distinction: Preserve historical versions and contrary evidence. ## Assurance case A scoped claim, supporting argument, evidence, limitations, and review decision. Distinction: A generated narrative cannot replace source evidence. ## Not assessed No assessment within the stated projection/scope. Distinction: Neither a pass nor proof that evidence does not exist elsewhere. ## Fail closed Deny when the required permission basis cannot be established. Distinction: A verified, fresh cache is an explicit admitted basis, not an error bypass. # External references - [NIST Risk Management Framework, SP 800-37 Rev. 2](https://csrc.nist.gov/pubs/sp/800/37/r2/final) — Federal context: system lifecycle, assessment, authorization, and monitoring. Conceptual alignment is not agency authorization. - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) — Voluntary framework for context-dependent AI risk management; not a certification of Licet. - [NIST AI Agent Standards Initiative](https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative) — Current identity, interoperability, and security work. Licet does not claim NIST endorsement or conformance. - [Retrieval practice vs. elaborative encoding · 2025 review](https://doi.org/10.1007/s10648-025-10076-6) — Informs active recall with feedback. Results are context-dependent; this hub has not been evaluated for learning gains. - [Retrieval in stepwise worked examples · 2025 study](https://doi.org/10.1016/j.learninstruc.2025.102196) — Informs predict-then-explain exercises. The study’s results do not establish effectiveness for this professional audience. - [Organizing instruction and study · IES practice guide](https://ies.ed.gov/ncee/WWC/PracticeGuide/1) — Foundational guidance for worked examples, graphical/verbal explanations, retrieval, and spacing.