goodLAC — Local Agent Controller
Central invariant: Model output is never authorization.
The problem

Keep proposal separate from permission

AI agents increasingly request consequential actions. The model can express intent, but it should not become the permission system or the executor. goodLAC places a deterministic control boundary between an agent harness and the effects it may request.

Agent / harness→goodLAC→policy · identity · approvals · leases→bounded effect

What goodLAC provides

A controller-owned authority boundary

Deterministic authority

Capability registration, policy, identity, exact approvals, and deny precedence are evaluated by the controller.

Bounded effects

Policy is re-evaluated before dispatch, with leases, idempotency, durable receipts, and effect truth.

Interruptible operation

Emergency pause and fail-closed handling keep consequential execution under explicit owner and system control.

Separated credentials

Credentials and privileged executors remain outside the untrusted model or agent context.

Evaluate first

Run the synthetic permission demo without provisioning the full model runtime.

Quick evaluation →

Install the governed path

Provision the exact qualified dependencies, build the deterministic distribution, install it, and run lac-doctor.

Installation →

Understand permissions

Capability registration, standing policy, and exact approval are separate authority concepts.

Permission model →

Know the boundary

rc.12 has explicit limitations, including no generic provider/adapter first-connect admission gate.

Release & limitations →

Release and integration

Start with the accepted release

1.0.0-rc.12 is the current accepted release candidate and the first release intended for ordinary public use. The main branch is the current public development/publication state and may contain post-release fixes; it is not the historical rc.12 source snapshot.

What this manual covers

This documentation applies specifically to 1.0.0-rc.12, the first goodLAC release intended for ordinary public use. It covers the qualified Linux reference path, default-governed Pi, project identity, permissions, owner administration, provider and external-consumer boundaries, security architecture, durable effect truth, troubleshooting, rollback, licensing, support, and public project policy.

Qualified reference path

Community and trust

Choose the right public channel

Discussions

Ask questions, share integration experience, and follow project updates in the community.

Join Discussions →

Issues

Use the structured forms for reproducible bugs and bounded feature requests.

Open an issue →

Security

Do not disclose vulnerabilities publicly. Use GitHub Private Vulnerability Reporting.

Report privately →

Roadmap

Read the directional architectural roadmap and distinguish tested configurations from certification.

View roadmap →