Four professional workspaces
Counsel resolves authority and scope; an authorizing official inspects a package; security tests a bypass; a developer checks exact-call bindings and adapter failure behavior.
CONTINUOUS CASE / FICTIONAL
Meridian’s agent: from mandate to accountable decision.
The agent may investigate assigned cases and draft recommendations. A sponsor proposes account closure. Review the applicable policy edition and attributed interpretation, map every executor path, then assess a new bulk-close worker and a known revocation during an outage.
Consequences carry forward
Releasing unreviewed closure through an unguarded worker produces contrary evidence in this teaching branch. Holding the tool avoids that modeled side effect, but incomplete observations still cannot prove universal non-execution.
A bounded next decision
Keep closure outside routine authority. Review a fresh read-and-draft authorization separately, assign accountable reviewers, and obtain complete independent reconciliation. Neither signature nor ALLOW proves compliance.
Interactive branches require scripting. These summaries preserve the central case reasoning without it.
UNFAMILIAR TRANSFER CASE
Apply the model to purchasing.
A purchasing agent proposes 30 units; its approval covers 20. The ALLOW receipt references an older record version. A checkpoint is within its age window, but authenticated revocation has since arrived. No independent order receipt is supplied.
Make your decision before reviewing these criteria
Stop the changed side effect. Revalidate exact action, approval and governing version. Known revocation removes the permission basis even inside the cache window. Execution is unestablished; request independent executor outcome and complete reconciliation. Explain the decisive facts and accountable next step.
Interactive scoring uses five structured criteria plus human review of a rationale. It is not certification.
LEARNING VALIDATION
Test transfer, retention and reasoning.
The interactive experience retains a first-attempt diagnostic, an unfamiliar transfer result, confidence and optional human rubric review, and offers delayed recall after 24 hours. All records stay in the browser. The items are not validated as equivalent measures, and no learner study has been run.
A proposed comparative study uses the same content in a static comparison arm, stratifies by role and prior experience, counterbalances unseen scenarios, and uses blinded human rationale scoring with reviewer agreement and uncertainty reporting.
Download the proposed study protocol and rubric ↓GUIDED LEARNING / EIGHT SHORT LESSONS
From permission to accountable action.
Licet connects institutional authority, a bounded permission, and the evidence needed to review an automated decision. Start with these eight practical lessons. Interactive checks are available when scripting is enabled; the essential ideas are all here.
LESSON 1 / 5 min
Why an authorization layer?
An agent can call a tool. That does not answer who permitted the action, within which limits, or what evidence shows it stayed there.
What you will learn: Separate capability, permission, and proof of execution.
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.
A worked example
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.
LESSON 2 / 7 min
Trace the authority chain
The record is useful because you can follow the reasoning—not just see that someone approved it.
What you will learn: Follow one condition from source to revalidation.
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.
A worked example
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.
LESSON 3 / 6 min
Define the operating boundary
Authorize a bounded system, not an unlimited promise that an agent will behave well.
What you will learn: Describe scope and identify a scope expansion.
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.
A worked example
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.
LESSON 4 / 8 min
Fit Licet into your ecosystem
Your orchestrator still plans. Your identity platform still identifies. Your executor still acts. The authorization layer connects permission to a particular action.
What you will learn: Place the check before the side effect and bind the resulting evidence.
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.
A worked example
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.
LESSON 5 / 7 min
Read evidence without overclaiming
A strong evidence culture makes “not assessed” visible. It does not turn missing information into a green badge.
What you will learn: State what an artifact proves and what it leaves unknown.
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.
A worked example
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.
LESSON 6 / 6 min
Handle outages and change
An enforcement point still has to decide when the registry cannot answer. That decision needs a defined freshness policy.
What you will learn: Explain fail-closed behavior and the limit of offline authorization.
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.
A worked example
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.
LESSON 7 / 6 min
Reduce friction by design
The goal is useful autonomy within a reviewed boundary. Less friction is a hypothesis to validate, not a reason to weaken the boundary.
What you will learn: Design a pilot that tests both protection and workflow cost.
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.
A worked example
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.
LESSON 8 / 8 min
Put the whole chain to work
A new bulk-close tool appears after a support agent’s boundary was reviewed. The existing record permits investigation and recommendations only.
What you will learn: Apply the model to a changed execution path and define the next decision.
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.
A worked example
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.
DECISION LAB / FICTIONAL WORKED CASE
What changes the permission?
A support agent may investigate its assigned case and draft a closure recommendation. In this teaching profile, executing closure requires a current human approval of the exact action.
Credentials, but no approval
Deny closure. Technical access does not establish institutional permission. Request the appropriate review before the side effect.
Approval, but the wrong case
Deny the expansion. An approval does not widen the assigned resource boundary.
Exact approval and current scope
Permission may be allowed in this fictional profile. Execution still needs a separate receipt. A stale or revoked permission basis denies.
This is a teaching case, not a production gate or implemented rich agent profile.
THE LEXICON
Clear words. Precise claims.
Authorization
Institutional permission for a bounded system/version under a defined approval rule.
Not a legal compliance finding or proof of execution.Boundary
The system description and scope against which conditions are derived.
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.
Richer profiles need validated enforcement bindings.Authority
A source of requirements: law, regulation, contract, standard, or internal policy.
Their binding force differs; applicability needs a basis.Applicability
The decision that a requirement matters to this system in this context and time.
A citation is not itself an applicability decision.Interpretation
Attributed institutional judgment about what a requirement means here.
AI drafting cannot create authority or accept risk.Policy pack
Institutional rules that determine authorization roles and approval readiness.
Different from the corpus that derives conditions.Corpus
Authored authority editions, rules, and interpretations used in derivation.
Not an exhaustive legal analysis of arbitrary prose.Condition
A derived operating requirement connected to the authority chain.
Documentation does not prove implementation.Control
A mechanism intended to satisfy a condition.
It needs implementation and effectiveness evidence.Evidence obligation
A statement of what should be collected to support a condition.
Not evidence already collected.Collection specification
Instructions for how evidence should be obtained.
Not a successful collection result.Risk acceptance
An accountable decision by a role authorized under institutional policy.
Cannot silently waive a mandatory duty or prohibition.Digest
A content hash identifying exact canonical bytes.
A hash alone does not establish truth or trusted identity.Signature
Cryptographic evidence that a key signed specified bytes.
Key trust and human attribution need separate checks.Canonicalization
A deterministic representation used for signing and hashing.
Visually identical text may differ at the byte level.Registry
A source of version, lifecycle, and revalidation context for authorizations.
A public record snapshot is not a live registry response.Checkpoint
Signed registry status and freshness information bound to a snapshot.
Cannot reveal a revocation occurring after it was issued.Gate
An evaluator returning a permission verdict and its basis for a proposed action.
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.
A prompt instruction is not a non-bypassable enforcement point.Decision receipt
A record of evaluation for an exact request and authorization version.
ALLOW does not mean executed.Execution receipt
Evidence of an action reported by the executing system.
Its provenance and completeness still need assessment.Revalidation
Review required by a change, failure, or uncertainty affecting authorization.
Preserve historical versions and contrary evidence.Assurance case
A scoped claim, supporting argument, evidence, limitations, and review decision.
A generated narrative cannot replace source evidence.Not assessed
No assessment within the stated projection/scope.
Neither a pass nor proof that evidence does not exist elsewhere.Fail closed
Deny when the required permission basis cannot be established.
A verified, fresh cache is an explicit admitted basis, not an error bypass.TECHNICAL REFERENCE
Where Licet fits in your ecosystem.
Your orchestrator plans, IAM identifies and grants technical access, and your executor performs the action. The proposed integration evaluates institutional permission at a point that can stop the side effect and links the resulting decision to independent execution evidence.
The inspected prototype exposes POST /api/v1/licet/contracts/{contract_id}/gate, accepting a required tool and optional data_domain and target. A decision reference and evaluated record version identify the permission basis. ALLOW is not an execution receipt.
Production adoption requires trusted identity and keys, full executor coverage, explicit outage/revocation handling, and assessed operational evidence. This website is separate from the application API.
For engineers: download the detailed specification ↓SOURCES & METHOD
Learn the distinctions. Apply them to a new decision.
These lessons use worked examples, explanatory feedback, active recall, and delayed review. They explain the research prototype and label proposed integrations. Course completion is not certification, agency authorization, or a compliance determination.
Federal context: system lifecycle, assessment, authorization, and monitoring. Conceptual alignment is not agency authorization.
Voluntary framework for context-dependent AI risk management; not a certification of Licet.
Current identity, interoperability, and security work. Licet does not claim NIST endorsement or conformance.
Informs active recall with feedback. Results are context-dependent; this hub has not been evaluated for learning gains.
Informs predict-then-explain exercises. The study’s results do not establish effectiveness for this professional audience.
Foundational guidance for worked examples, graphical/verbal explanations, retrieval, and spacing.