mirror of
https://github.com/profullstack/logicsrc.git
synced 2026-08-13 22:37:29 +00:00
Add the LogicSRC OpenContext specification
OpenContext is an open specification for durable, portable, permissioned, provenance-aware context shared between humans and AI agents. It defines how organizational knowledge is described, authorized, versioned, resolved, audited, and handed between replaceable workers without losing institutional state. Follows the OpenPRD/OpenOntology pattern already in the repo: self-contained JSON Schemas in @logicsrc/schemas, a reference implementation package, CLI subcommands, docs, examples, and an OpenPRD record. Schemas (8, all self-contained so a third party can fetch one file and validate against it with no further resolution): manifest, object, bundle, role, provenance, decision, diagnostic, audit-event — registered in @logicsrc/validators and schemas:validate. Reference implementation (@logicsrc/opencontext): loader with upward manifest discovery, the full resolution pipeline, authority/supersession, permissions, redaction, lifecycle, provenance, deterministic digests, doctor, search, graph, history/diff, guarded writes, audit events, and file/http/git/sqlite adapters. CLI: all 15 specified commands, as a standalone `opencontext` binary and as `logicsrc context`, sharing one implementation so the two cannot drift. Design decisions worth noting: - Supersession is declared, never inferred from version numbers. Inferring it would hide the governance failure it represents and make multiple-active-versions and duplicate-canonical impossible to detect. - The bundle digest identifies the resolved context, not the moment it was computed, so generated_at/bundle_id/digest/as_of are excluded while objects, lifecycle states, exclusions and warnings are covered. That is what lets a decision record cite exactly the context that produced it. - A role's own max_classification beats an inherited one, so a ceiling on a shared base role cannot silently cap a role deliberately granted more; requesting several roles at once still takes the lowest, so combining roles never escalates. - Scope wildcards match whole dotted segments only. A trailing .* covers a subtree; an interior * matches exactly one segment. Substring matching here would be an access-control bug. - --include narrows an existing scope and is applied after it, never merged into it, so a request can never widen what a role holds. Verified: 226 tests across core primitives, permissions/redaction, the resolution pipeline, security, the published conformance fixtures (13 valid, 35 invalid, 8 resolution scenarios), project behaviour, and the five shipped examples — which are held to --strict and a 100% health score. Benchmarks meet every published budget (resolve 1,000 objects in ~33ms against a 2s target). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
1bb7ba6e60
commit
ec3ed64f20
211 changed files with 17234 additions and 6 deletions
50
examples/opencontext/multi-agent-company/README.md
Normal file
50
examples/opencontext/multi-agent-company/README.md
Normal file
|
|
@ -0,0 +1,50 @@
|
|||
# Multi-agent company
|
||||
|
||||
One shared context repository. Five agents. Five different bundles.
|
||||
|
||||
```bash
|
||||
opencontext validate --strict
|
||||
opencontext doctor
|
||||
|
||||
for agent in sales-agent support-agent dev-agent finance-agent ops-agent; do
|
||||
echo "== $agent"
|
||||
opencontext resolve --agent "$agent" --explain
|
||||
done
|
||||
```
|
||||
|
||||
## What each agent gets
|
||||
|
||||
| Agent | Sees | Never sees |
|
||||
| --- | --- | --- |
|
||||
| `sales-agent` | products, customers, pricing, quoting SOP | churn risk, payroll, architecture |
|
||||
| `support-agent` | products, customers, refunds, refund SOP | pricing, payroll, architecture |
|
||||
| `dev-agent` | architecture, change management, decisions | customers, pricing, payroll |
|
||||
| `finance-agent` | every policy including payroll, customers | architecture, runbooks, card numbers |
|
||||
| `ops-agent` | procedures, runbooks, change management | customers, pricing, payroll |
|
||||
|
||||
## Three mechanisms doing the work
|
||||
|
||||
**Scope.** Each role includes only what it needs. `sales` additionally excludes
|
||||
`customers.*.churn-risk`, so an inferred model score cannot leak into a customer
|
||||
conversation even though `customers.*` matches it.
|
||||
|
||||
**Classification.** `policies.payroll` is `confidential`. Only `finance`
|
||||
declares `max_classification: confidential`; every other role falls back to
|
||||
`internal` and is refused. A role's own declaration wins over the one it
|
||||
inherits, so a ceiling on a shared base role cannot silently cap a role that was
|
||||
deliberately granted more — while requesting several roles at once still takes
|
||||
the lowest of them, so combining roles never escalates.
|
||||
|
||||
**Redaction.** The manifest redacts `payment.card` repository-wide, so no role —
|
||||
including `finance` — ever receives a card number, even from a record it is
|
||||
fully entitled to read.
|
||||
|
||||
**Object permissions.** `policies.payroll` also carries
|
||||
`permissions.read: [finance]`, so it is refused even to a role whose include
|
||||
pattern matches it. Deny overrides allow, at every level.
|
||||
|
||||
## The point
|
||||
|
||||
Replace `support-agent` with a different model tomorrow. Run the same command.
|
||||
The bundle is identical, and its digest proves it. The agent was replaceable;
|
||||
the context was not.
|
||||
Loading…
Add table
Add a link
Reference in a new issue