eric-sdk 0.1.6 → 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 +49 -48
  2. package/README.md +73 -48
  3. package/package.json +1 -1
package/CHANGELOG.md CHANGED
@@ -2,34 +2,52 @@
2
2
 
3
3
  All notable changes to the Eric SDK are documented here.
4
4
 
5
- This project follows semantic versioning.
6
- Pre-1.0 releases may introduce intentional breaking changes as the API surface evolves.
5
+ This project follows semantic versioning.
6
+ Pre-1.0 releases may introduce breaking changes as the API surface and governance model stabilize.
7
7
 
8
8
  ---
9
9
 
10
- ## [0.1.6] – 2026-02-25
10
+ ## [0.1.8] – 2026-06-09
11
+
12
+ ### Documentation
11
13
 
12
- ## Changed
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.
13
19
 
14
- Added repository, homepage, and issues metadata to package.json.
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
+ ---
15
23
 
16
- Rationale
24
+ ## [0.1.7] – 2026-05-06
17
25
 
18
- Improves npm package transparency and traceability by linking the SDK to its public GitHub source, issue tracking, and documentation.
19
- No runtime behavior changes.
26
+ ### Documentation
27
+
28
+ - Rewrote README to better reflect the SDK's role as an execution control layer.
29
+
30
+ **Rationale:** The previous README underemphasized the governance model and led with authentication rather than how the SDK actually works. Updated to open with the execution pipeline, added a "How it works" section covering all five enforcement steps, expanded the security section with specific properties, and restructured usage examples to lead with a complete quick start. No runtime behavior changes.
20
31
 
21
32
  ---
22
33
 
23
- ## [0.1.5] – 2026-02-24
34
+ ## [0.1.6] – 2026-02-25
24
35
 
25
36
  ### Changed
26
37
 
27
- * Narrowed `type` in response shape from `string` to `"structured" | "text"`.
38
+ Added `repository`, `homepage`, and `issues` metadata to `package.json`.
39
+
40
+ **Rationale:** Improves npm package transparency by linking the SDK to its public GitHub source, issue tracker, and documentation. No runtime behavior changes.
41
+
42
+ ---
28
43
 
29
- ### Rationale
44
+ ## [0.1.5] – 2026-02-24
45
+
46
+ ### Changed
30
47
 
31
- Response format classification is now explicitly constrained.
32
- This prevents accidental drift in output types and strengthens the SDK’s deterministic contract.
48
+ - Narrowed `type` in response shape from `string` to `"structured" | "text"`.
49
+
50
+ **Rationale:** Response format classification is now explicitly constrained. Prevents accidental drift in output types and strengthens the SDK's deterministic contract.
33
51
 
34
52
  ---
35
53
 
@@ -37,73 +55,56 @@ This prevents accidental drift in output types and strengthens the SDK’s deter
37
55
 
38
56
  ### Changed
39
57
 
40
- - Added `engines` field specifying Node.js >=20.
58
+ - Added `engines` field specifying `node >=20`.
41
59
 
42
60
  ---
43
61
 
44
62
  ## [0.1.3] – 2026-02-06
45
63
 
46
- ### Changed:
47
-
48
- * **Removed `client` from request payload**: The SDK no longer includes `client` in the request body when calling `decide()`.
49
-
50
- ### Rationale:
64
+ ### Changed
51
65
 
52
- `client` is infrastructure identity and is now treated as authoritative header-only metadata (`x-api-client`).
53
- This change removes ambiguity, prevents spoofing, and aligns the SDK with Eric’s control-plane model, where execution authority lives outside user-provided input.
66
+ - Removed `client` from the `decide()` request payload.
54
67
 
55
- ### Notes:
68
+ **Rationale:** `client` is infrastructure identity and is now treated as authoritative header-only metadata (`x-api-client`). Removing it from the request body prevents spoofing and aligns the SDK with Eric's control-plane model, where execution authority lives outside user-provided input.
56
69
 
57
- * Applications must continue to provide `x-api-client` and `x-api-key` headers.
58
- * Requests that previously included `client` in the body may be rejected by strict API validation.
70
+ **Note:** Requests that previously included `client` in the body may be rejected by strict API validation.
59
71
 
60
72
  ---
61
73
 
62
74
  ## [0.1.2] – 2026-02-03
63
75
 
64
- ### What's New:
65
-
66
- * **Updated API Endpoint**: The SDK now calls the API endpoint at `https://us-central1-eric-ai-prod.cloudfunctions.net/decide` for decision-making flows.
76
+ ### Changed
67
77
 
68
- ### Breaking Changes:
78
+ - Updated API endpoint to `https://us-central1-eric-ai-prod.cloudfunctions.net/decide`.
69
79
 
70
- * **Endpoint Change**: If you were using the previous `decide` endpoint, please update the SDK configuration to use the new endpoint.
80
+ **Note:** If you were calling the previous endpoint directly, update your SDK to this version.
71
81
 
72
82
  ---
73
83
 
74
84
  ## [0.1.1] – 2026-01-30
75
85
 
76
- ### Changed:
77
-
78
- * Removed explicit `flow: "decisionRouter"` from SDK requests.
86
+ ### Changed
79
87
 
80
- ### Rationale:
88
+ - Removed explicit `flow: "decisionRouter"` from SDK requests.
81
89
 
82
- The Eric API no longer accepts direct flow invocations.
83
- All requests are now treated as intent submissions and are routed through the internal decision router by default. This change simplifies the SDK payload and prevents accidental coupling to internal execution details.
90
+ **Rationale:** The Eric API no longer accepts direct flow invocations. All requests are now treated as intent submissions and routed through the internal decision router by default. Simplifies the SDK payload and prevents coupling to internal execution details.
84
91
 
85
92
  ---
86
93
 
87
94
  ## [0.1.0] – 2026-01-27
88
95
 
89
- ### Changed:
90
-
91
- * Removed `client.call()` to prevent direct flow invocation.
92
- * All executions must now be routed through `decide()`.
96
+ ### Changed
93
97
 
94
- ### Rationale:
98
+ - Removed `client.call()`. Direct flow invocation is no longer supported.
99
+ - All executions must now be routed through `decide()`.
95
100
 
96
- Direct flow execution allowed applications to bypass policy enforcement. Eric is designed as a governance and control layer, and all execution must pass through policy evaluation to ensure deterministic, auditable outcomes. This release intentionally narrows the public API to reflect Eric’s execution model.
101
+ **Rationale:** Direct flow execution allowed applications to bypass policy enforcement. Eric is a governance and control layer — all execution must pass through policy evaluation to ensure deterministic, auditable outcomes. This release intentionally narrows the public API to reflect that model.
97
102
 
98
103
  ---
99
104
 
100
105
  ## [0.0.5] – 2025-12-14
101
106
 
102
- ### Added:
103
-
104
- * Initial public SDK release.
105
- * `decide()` with policy-based routing and optional execution bounds.
106
-
107
- ---
107
+ ### Added
108
108
 
109
- This version ensures clarity and consistency across all sections while providing users with the necessary context on each update.
109
+ - Initial public SDK release.
110
+ - `decide()` with policy-based routing and optional execution bounds via `allowedFlows`.
package/README.md CHANGED
@@ -1,11 +1,14 @@
1
1
  # Eric SDK (JavaScript / TypeScript)
2
2
 
3
- Official SDK for interacting with **Eric AI**, a policy-governed execution layer for AI systems.
3
+ Official SDK for **Eric AI** - a centralized governance layer for AI applications.
4
4
 
5
- Eric is designed for environments where AI behavior must be **controlled, deterministic, and auditable**.
6
- All requests are evaluated against configured policy before any capability is executed.
5
+ Most organizations don't have one AI application anymore. They have many.
7
6
 
8
- This SDK exposes a single, safe interaction model that enforces those guarantees by default.
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.**
9
12
 
10
13
  ---
11
14
 
@@ -15,11 +18,11 @@ This SDK exposes a single, safe interaction model that enforces those guarantees
15
18
  npm install eric-sdk
16
19
  ```
17
20
 
18
- ---
21
+ Requires an Eric-issued API key. [Request access →](https://ericaicontrol.dev)
19
22
 
20
- ## Authentication
23
+ ---
21
24
 
22
- You will need an Eric-issued API key.
25
+ ## Quick start
23
26
 
24
27
  ```ts
25
28
  import { EricSDK } from "eric-sdk";
@@ -28,81 +31,100 @@ const eric = new EricSDK({
28
31
  apiKey: process.env.ERIC_API_KEY!,
29
32
  client: "your-app-id",
30
33
  });
34
+
35
+ const result = await eric.decide({
36
+ text: "Summarize the provided patient record",
37
+ requestType: "clinicalSummary",
38
+ });
39
+
40
+ // result.flow - resolved capability
41
+ // result.type - "structured" | "text"
42
+ // result.data - schema-validated output
31
43
  ```
32
44
 
33
- API keys are scoped and governed server-side.
34
- Keys should be treated as secrets and stored securely.
45
+ API keys are scoped and governed server-side. Never embed them in client-side code or public repositories.
35
46
 
36
47
  ---
37
48
 
38
- ## Security Notice
49
+ ## How it works
39
50
 
40
- This SDK enforces server-side policy and execution controls.
51
+ Applications invoke Eric through a single API.
41
52
 
42
- API keys must be stored securely and never embedded in public repositories.
53
+ Eric applies governance before any model is executed.
43
54
 
44
- ---
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
45
62
 
46
- ## Usage
63
+ If any governance check fails, execution stops. No fallback. No silent substitution. No model is invoked.
47
64
 
48
- ### Policy-Governed Execution
65
+ ---
49
66
 
50
- All interactions with Eric are routed through `decide()`.
67
+ ## Governing approved capabilities
51
68
 
52
- Eric evaluates each request against policy, routing constraints, and execution bounds before selecting and invoking an approved capability.
69
+ Applications do not invoke models directly.
53
70
 
54
- ```ts
55
- const result = await eric.decide({
56
- text: "summarize the provided content",
57
- requestType: "summary",
58
- });
59
- ```
60
-
61
- ---
71
+ Applications invoke approved capabilities.
62
72
 
63
- ### Optional Execution Bounds
73
+ Eric determines whether a capability is authorized, applies governance controls, and routes execution to the appropriate AI provider.
64
74
 
65
- You may optionally restrict which capabilities are eligible for execution.
75
+ Use `allowedFlows` to further restrict which capabilities are eligible for a specific request.
66
76
 
67
77
  ```ts
68
78
  await eric.decide({
69
- text: "Generate a structured daily summary for the provided input",
79
+ text: "Generate a structured daily summary",
70
80
  allowedFlows: ["dailySummary"],
71
81
  });
72
82
  ```
73
83
 
74
84
  When `allowedFlows` is provided:
75
85
 
76
- - Only capabilities in the allowed set are eligible for execution.
77
- - If resolution falls outside the allowed set, execution is denied.
78
- - No fallback or automatic substitution occurs.
86
+ - Only capabilities in the allowed set are eligible
87
+ - If no match is found, execution is denied and logged
88
+ - No fallback or automatic substitution occurs
89
+
90
+ This provides request-level governance on top of deployment-level capability controls.
79
91
 
80
92
  ---
81
93
 
82
- ## Response Shape
94
+ ## Response shape
83
95
 
84
96
  ```ts
85
97
  {
86
- flow: string; // resolved capability
87
- type: "structured" | "text"; // output format classification
88
- data: unknown; // structured object or text result
98
+ flow: string; // resolved capability
99
+ type: "structured" | "text"; // output format
100
+ data: unknown; // schema-validated output
89
101
  }
90
-
91
102
  ```
92
103
 
93
- All responses conform to pre-approved output contracts.
104
+ All responses conform to capability-level output contracts. Every field is validated before being returned to the application.
105
+
106
+ ---
107
+
108
+ ## Security & Governance
94
109
 
95
- All fields are guaranteed to be present according to the executed capability’s contract.
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
96
116
 
97
117
  ---
98
118
 
99
- ## Design Principles
119
+ ## Design principles
100
120
 
101
- * **Policy-first execution** — no direct or bypassed calls
102
- * **Deterministic behavior** — predictable outputs by design
103
- * **Auditability** — every decision and execution is logged
104
- * **Infrastructure-grade** — built for production systems, not chatbots
105
- * **Intent-based API** — clients describe what they want, not what to run
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
106
128
 
107
129
  ---
108
130
 
@@ -110,9 +132,7 @@ All fields are guaranteed to be present according to the executed capability’s
110
132
 
111
133
  The Eric SDK follows semantic versioning.
112
134
 
113
- Breaking changes reflect deliberate enforcement of governance and safety guarantees.
114
-
115
- 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.
116
136
 
117
137
  See `CHANGELOG.md` for details.
118
138
 
@@ -121,6 +141,11 @@ See `CHANGELOG.md` for details.
121
141
  ## Support
122
142
 
123
143
  For access, onboarding, or documentation:
124
- [https://ericaicontrol.dev](https://ericaicontrol.dev)
125
144
 
145
+ https://ericaicontrol.dev
146
+
147
+ ---
148
+
149
+ **Eric AI**
126
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.6",
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",