Living Promises (experimental authority foundation)

Living Promises retain an owner’s original request, commitment, criteria, constraints and relevant Workspace repository keys as immutable versions in the Hub. A signed-in Workspace human with Reader and Contributor roles and grants for every declared key can create a promise or adopt an agent proposal. The creator becomes steward. Agent tokens are scoped to one repository key: they can read promises confined to that key and submit proposals or reports. Multi-repository promises are hidden from those tokens, and agents cannot report on them. Agent inputs are advisory and cannot create, amend or retire an owner promise. The Workspace Promises page exposes creation, proposal review and adoption, current versions, history, reports and available owner actions.

The active steward can amend, correct, retire or transfer a promise. Each change carries a reason and the exact expected version and digest. Amendment records a deliberate new commitment or scope; correction records that a previous account was wrong. Neither rewrites an earlier version. Recovery transfer is limited to an administrator when the prior steward is no longer eligible. A recipient must already be eligible for the complete scope. Before an owner mutation, the browser preflights the proposed repository keys and displays the server’s current source admissions. The mutation freezes their digest in expected_admissions_digest. Preflight does not reserve a mapping: if it changes before an uncommitted mutation, the write conflicts without creating a promise or version. The server rechecks live roles, grants, recipient eligibility and the expected version during the write. A client supplied operation_id returns its retained receipt on an exact retry after current authentication and read grants; a different body or target cannot reuse it. A committed receipt hidden by a later source remapping stays retained and can replay when its original admission returns.

Repository IDs in a promise are configured Workspace grant keys, not repository display names. An operator may add forge_repositories to the private Workspace JSON configuration, binding each key to a connected forge identity:

{"forge_repositories":[{"repository_id":"synthetic/project","provider":"github","host":"github.com","forge_repository_id":12345}]}

The numeric ID must be a JSON integer identifying a currently connected repository on that provider and host. Native execution profiles supply their admitted native repository identities. The server captures the current identities for each key in the immutable version or input, includes version admissions in its digest, and checks current mappings on every read and retry. Reads require a self-valid retained version, including its own digest and exact promise and version identity, before its complete source scope can establish authority. An unreadable or digest-invalid version, or metadata that cannot establish current source authority, stays hidden. An unreadable retained version can hide the whole history or report page even while the current promise remains readable. After a valid authorized payload passes source checks, pointer and exact-index mismatches report integrity errors; duplicate individually current metadata entries fail aggregate integrity validation. Report lists check current-parent integrity after any cursor’s own visibility check. PostgreSQL JSONB can normalize manually damaged numeric encodings differently from SQLite text storage, so an exponent’s visibility depends on the retained representation. A key with neither source is explicitly unbound. Changing key K from forge repository A to B hides A’s retained versions and inputs while B is current; restoring A restores their visibility. Agent tokens must also match the current numeric binding, or be unbound when the key is unbound. Current Workspace membership and repository grants remain necessary in every case. A promise may name at most eight keys in one version and 64 distinct keys across its lifetime. Removing a key and later re-adding it with a different source admission conflicts; use a new configured key instead. To move an existing promise to a new source, restore its admitted mapping first, then have an authorized steward amend it using a separately configured key. A renamed repository display string does not authorize access.

The current foundation retains reports as caller statements. Browser-submitted proposals are also advisory and capture their single repository’s admission when committed; they do not receive the owner mutation preflight guarantee. The foundation does not resolve affected Work, attach check-specific evidence, assess fulfillment, or infer a promise passed from CI or deployment status. A version digest identifies the owner’s recorded commitment and source admission; it is not a verification result. This alpha interface and its storage schema may change.

Promise list pages contain at most the requested number of visible promises and use the last visible promise ID as their cursor. For a reader granted specific repository keys, the Hub starts from workspace-qualified version repository index entries for those keys, then checks the complete current scope and admission before returning a promise. A browser reader granted * uses the unrestricted workspace path. Rows for entirely ungranted keys do not enter the specific-key candidate set. Each page materializes the remaining granted-key index entries after its cursor, even when every promise is visible. Older versions, stale admissions and promises that also name ungranted keys can add work before a page fills; this is not a constant-time query. A damaged promise with no current index entry for any granted key cannot be discovered by the specific-key list, although direct authorized reads check index integrity. Input lists and history remain scoped to their requested repository or promise.

The agent CLI supports agentscm promise list, show ID, history ID, propose --request FILE and report --request FILE. - reads strict JSON from standard input for proposal and report. The corresponding authenticated Hub HTTP and MCP interfaces use the same Workspace authorization and immutable records.