eric-sdk 0.1.7 → 0.1.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/CHANGELOG.md +14 -0
  2. package/README.md +59 -36
  3. package/package.json +1 -1
package/CHANGELOG.md CHANGED
@@ -7,6 +7,20 @@ Pre-1.0 releases may introduce breaking changes as the API surface and governanc
7
7
 
8
8
  ---
9
9
 
10
+ ## [0.1.8] – 2026-06-09
11
+
12
+ ### Documentation
13
+
14
+ - Repositioned README around centralized AI governance.
15
+ - Updated SDK description to reflect Eric's role as a governance layer across applications and AI models.
16
+ - Added governance-focused overview and architecture explanation.
17
+ - Renamed capability section to emphasize approved capability governance.
18
+ - Expanded design principles with centralized governance and model-agnostic operation.
19
+
20
+ **Rationale:** Eric's platform positioning has evolved from an execution-control-focused runtime description to a centralized governance layer for AI applications. The README now leads with the organizational problem Eric solves—governance fragmentation across applications—while preserving the existing technical implementation details. No runtime behavior changes.
21
+
22
+ ---
23
+
10
24
  ## [0.1.7] – 2026-05-06
11
25
 
12
26
  ### Documentation
package/README.md CHANGED
@@ -1,10 +1,14 @@
1
1
  # Eric SDK (JavaScript / TypeScript)
2
2
 
3
- Official SDK for **Eric AI** — the execution control plane for production AI systems.
3
+ Official SDK for **Eric AI** - a centralized governance layer for AI applications.
4
4
 
5
- Every request is evaluated against declared policy before any capability executes. No model is invoked until intent is classified, policy is cleared, and a registered capability is matched. Every execution — allowed or blocked — is logged with an immutable audit trail.
5
+ Most organizations don't have one AI application anymore. They have many.
6
6
 
7
- Built for environments where AI behavior must be **controlled, deterministic, and auditable**.
7
+ As AI adoption grows, governance becomes fragmented. Different applications implement different controls, different audit trails, different policies, and often different AI providers.
8
+
9
+ Eric sits between applications and AI models, applying capability authorization, policy enforcement, output compliance, and audit logging consistently before execution reaches a model.
10
+
11
+ **One Governance Layer. Every Application. Any Model.**
8
12
 
9
13
  ---
10
14
 
@@ -33,9 +37,9 @@ const result = await eric.decide({
33
37
  requestType: "clinicalSummary",
34
38
  });
35
39
 
36
- // result.flow — resolved capability
37
- // result.type — "structured" | "text"
38
- // result.data — schema-validated output
40
+ // result.flow - resolved capability
41
+ // result.type - "structured" | "text"
42
+ // result.data - schema-validated output
39
43
  ```
40
44
 
41
45
  API keys are scoped and governed server-side. Never embed them in client-side code or public repositories.
@@ -44,25 +48,35 @@ API keys are scoped and governed server-side. Never embed them in client-side co
44
48
 
45
49
  ## How it works
46
50
 
47
- Your application calls `decide()`. Eric handles the rest:
51
+ Applications invoke Eric through a single API.
52
+
53
+ Eric applies governance before any model is executed.
48
54
 
49
- 1. **Intent classification** — the request is classified before any routing occurs
50
- 2. **Policy gate** — declared policy is evaluated in code, not in prompts
51
- 3. **Capability routing** — the request is routed deterministically to a registered capability
52
- 4. **Output validation** — the response is validated against a typed schema before it is returned
53
- 5. **Audit log** — every execution is recorded at the moment it occurs, immutably
55
+ 1. **Intent classification** - determine the requested business capability
56
+ 2. **Authorization** - verify the capability is approved for the client and application
57
+ 3. **Policy enforcement** - evaluate execution policy before model invocation
58
+ 4. **Capability routing** - route deterministically to the registered capability
59
+ 5. **Model execution** - invoke the configured AI provider
60
+ 6. **Output validation** - validate the response against the capability schema
61
+ 7. **Audit logging** - record the execution outcome with a complete audit trail
54
62
 
55
- If any check fails, execution stops. No fallbacks. No silent substitutions. No model is invoked.
63
+ If any governance check fails, execution stops. No fallback. No silent substitution. No model is invoked.
56
64
 
57
65
  ---
58
66
 
59
- ## Restricting execution to specific capabilities
67
+ ## Governing approved capabilities
68
+
69
+ Applications do not invoke models directly.
70
+
71
+ Applications invoke approved capabilities.
72
+
73
+ Eric determines whether a capability is authorized, applies governance controls, and routes execution to the appropriate AI provider.
60
74
 
61
- Use `allowedFlows` to restrict which capabilities are eligible for a given request.
75
+ Use `allowedFlows` to further restrict which capabilities are eligible for a specific request.
62
76
 
63
77
  ```ts
64
78
  await eric.decide({
65
- text: "Generate a structured daily summary for the provided input",
79
+ text: "Generate a structured daily summary",
66
80
  allowedFlows: ["dailySummary"],
67
81
  });
68
82
  ```
@@ -73,7 +87,7 @@ When `allowedFlows` is provided:
73
87
  - If no match is found, execution is denied and logged
74
88
  - No fallback or automatic substitution occurs
75
89
 
76
- This is equivalent to registering a capability restriction at the request level. For deployment-level restrictions, capability registration is handled during onboarding.
90
+ This provides request-level governance on top of deployment-level capability controls.
77
91
 
78
92
  ---
79
93
 
@@ -81,33 +95,36 @@ This is equivalent to registering a capability restriction at the request level.
81
95
 
82
96
  ```ts
83
97
  {
84
- flow: string; // resolved capability name
85
- type: "structured" | "text"; // output format
86
- data: unknown; // schema-validated output
98
+ flow: string; // resolved capability
99
+ type: "structured" | "text"; // output format
100
+ data: unknown; // schema-validated output
87
101
  }
88
102
  ```
89
103
 
90
- All responses conform to pre-approved output contracts defined at the capability level. Every field is guaranteed to be present according to the executed capability's schema.
104
+ All responses conform to capability-level output contracts. Every field is validated before being returned to the application.
91
105
 
92
106
  ---
93
107
 
94
- ## Security
108
+ ## Security & Governance
95
109
 
96
- - Policy is enforced server-side. The SDK cannot bypass or override execution controls.
97
- - API keys are scoped per client and governed server-side.
98
- - All executions — including blocked ones — are logged with a structured, timestamped, attributable record.
99
- - Customer data is not used to train third-party models.
100
- - BYOK (Bring Your Own Key) is supported for model providers. See onboarding documentation.
110
+ - Authorization and policy enforcement occur server-side
111
+ - API keys are scoped per client and governed centrally
112
+ - All executions - including blocked executions - are logged
113
+ - Customer data is never used to train third-party models
114
+ - BYOK (Bring Your Own Key) is supported for model providers
115
+ - Governance remains consistent regardless of underlying model provider
101
116
 
102
117
  ---
103
118
 
104
119
  ## Design principles
105
120
 
106
- - **Policy-first** — no direct model calls, no bypassed executions
107
- - **Deterministic** — the same request under the same policy produces the same routing decision
108
- - **Auditable** — every decision is logged at execution time, not reconstructed after
109
- - **Infrastructure-grade** — built for regulated production systems, not prototypes
110
- - **Intent-based** — clients describe what they want; the control plane decides what runs
121
+ - **Centralized governance** - one governance layer across applications
122
+ - **Capability-first** - applications invoke approved capabilities, not models
123
+ - **Policy-enforced** - execution controls are applied before model invocation
124
+ - **Deterministic** - the same request under the same policy produces the same routing decision
125
+ - **Auditable** - every decision is recorded at execution time
126
+ - **Model-agnostic** - governance remains consistent across providers
127
+ - **Infrastructure-grade** - built for production and regulated environments
111
128
 
112
129
  ---
113
130
 
@@ -115,9 +132,7 @@ All responses conform to pre-approved output contracts defined at the capability
115
132
 
116
133
  The Eric SDK follows semantic versioning.
117
134
 
118
- Breaking changes reflect deliberate updates to governance and safety guarantees, not implementation convenience.
119
-
120
- Pre-1.0 versions were experimental and are not supported.
135
+ Breaking changes reflect deliberate updates to governance guarantees and platform behavior, not implementation convenience.
121
136
 
122
137
  See `CHANGELOG.md` for details.
123
138
 
@@ -125,4 +140,12 @@ See `CHANGELOG.md` for details.
125
140
 
126
141
  ## Support
127
142
 
128
- For access, onboarding, or documentation: [https://ericaicontrol.dev](https://ericaicontrol.dev)
143
+ For access, onboarding, or documentation:
144
+
145
+ https://ericaicontrol.dev
146
+
147
+ ---
148
+
149
+ **Eric AI**
150
+
151
+ *One Governance Layer. Every Application. Any Model.*
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "eric-sdk",
3
- "version": "0.1.7",
3
+ "version": "0.1.8",
4
4
  "description": "Official SDK for enforcing policy-governed AI execution using the Eric AI governance layer",
5
5
  "author": "Rod Bridges",
6
6
  "license": "MIT",