SC-SMT is an AI and automated-decision governance layer designed to keep decisions and downstream actions aligned when the evidence or knowledge behind them changes.
Instead of treating new information as a simple memory update, SC-SMT evaluates how a change affects existing decisions, dependencies, authorizations, and actions.
The system can identify when a previously valid decision is no longer trustworthy, place dependent actions on hold, require revalidation against current authoritative evidence, and prevent stale authorizations from being used for execution.
https://github.com/vinnybellack/Verigate-SC-SMT/tree/VinodBalakrishnan
Modern AI and automated decision systems continuously operate on changing information.
A decision may have been valid when it was created, but the evidence behind that decision can later:
A conventional workflow may update the latest data without automatically determining which existing decisions and actions have become unsafe or stale.
This creates a critical governance problem:
What happens to an existing decision when the knowledge behind it changes?
SC-SMT is designed to address that problem.
AI systems that remain reliable when knowledge changes.
SC-SMT is intended to provide a governance layer between changing evidence and consequential automated actions.
The product tracks the relationship between:
Evidence ↓ Facts ↓ Rules / Decisions ↓ Downstream Dependencies ↓ Actions
When evidence changes, SC-SMT evaluates the affected dependency chain and determines what must happen next.
The core product workflow is:
Evidence ↓ Evidence Evaluation ↓ Semantic / State Change Detection ↓ Dependency Impact Analysis ↓ Decision Revalidation ↓ Authorization ↓ Execution-Time Validation ↓ External Action ↓ Audit Trail
The system is designed around three primary governance states:
The required checks have passed for the exact decision, evidence versions, policy version, and action parameters.
The action may proceed through the execution gateway.
A defined policy or governance rule explicitly prohibits the action.
The action must not proceed.
Required evidence, verification, dependency processing, or revalidation is incomplete or uncertain.
The action does not proceed until the governance condition is resolved.
The current MVP demonstrates a purchase approval scenario.
A purchase action depends on a vendor qualification.
Initially:
Vendor Qualification = VALID ↓ Decision = CURRENT ↓ Purchase Action = PENDING
When the qualification expires:
Vendor Qualification = EXPIRED ↓ Decision = REVALIDATION_REQUIRED ↓ Purchase Action = HOLD
A new qualification is then received and verified:
New Qualification = VERIFIED ↓ Decision = REVALIDATION_REQUIRED
The new evidence does not automatically authorize the old decision.
The decision must be revalidated:
Verified Evidence ↓ Decision REVALIDATED ↓ Authorization ↓ Execution-Time Validation ↓ Action EXECUTED
SC-SMT is not intended to be:
The core product idea is:
When the underlying evidence changes, determine what decisions and actions are affected and govern whether those decisions and actions can remain valid.
The distinction is therefore:
Traditional Decision System Current State ↓ What should I decide? SC-SMT Evidence changed ↓ What became affected? ↓ What must be revalidated? ↓ What actions must stop? ↓ Can the exact action still execute?
Evidence represents information received by the system.
Evidence is versioned and can carry:
Examples:
Vendor qualification Employee certification Contract approval Compliance status Purchase limit Security authorization Policy revision
SC-SMT distinguishes between different evidence conditions.
Examples include:
RECEIVED VERIFIED AUTHORITATIVE EXPIRED SUPERSEDED CONFLICTED QUARANTINED
An important product principle is that received evidence is not automatically authoritative evidence.
Decisions and actions depend on specific evidence or derived state.
For example:
vendor.qualification.status ↓ Purchase Approval Decision ↓ Submit Purchase Order Action
When the upstream evidence changes, SC-SMT identifies the affected downstream objects.
A decision represents a governed business or AI decision.
A decision may contain:
A decision that was previously valid can become:
CURRENT REVALIDATION_REQUIRED BLOCKED HOLD
depending on the governance condition.
Authorization is not treated as a permanent permission.
It is bound to the exact governed state used when the action was authorized.
The binding can include:
Evidence Version Policy Version Decision State Action Parameters
Therefore, changing the governed state can invalidate an existing authorization.
The execution gateway performs a final validation immediately before an external action is committed.
Conceptually:
Request Execution ↓ Is authorization active? ↓ Is decision still current? ↓ Are evidence bindings unchanged? ↓ Are action parameters unchanged? ↓ Are governance checks satisfied? ↓ EXECUTE
Otherwise:
HOLD / BLOCK
Every important governance transition records:
Example:
EVIDENCE CHANGED ↓ DECISION REVALIDATION REQUIRED ↓ ACTION HOLD ↓ EVIDENCE VERIFIED ↓ DECISION REVALIDATED ↓ ACTION AUTHORIZED ↓ ACTION EXECUTING ↓ ACTION EXECUTED
This creates a traceable governance history.
The current repository contains the first product-oriented implementation of SC-SMT.
The MVP currently includes:
The external action is currently simulated.
This is intentional: the MVP focuses on validating the governance mechanism before introducing production external connectors.
Current MVP stack:
Frontend HTML CSS JavaScript Backend Node.js Database SQLite Runtime Node.js 22+ Testing Node.js test framework Deployment Docker
The implementation currently avoids unnecessary third-party runtime dependencies.
┌─────────────────────┐ │ AI / Business Logic │ │ Decision System │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ SC-SMT │ │ │ │ Evidence Registry │ │ State Evaluation │ │ Dependency Engine │ │ Decision Governance │ │ Revalidation │ │ Authorization │ │ Execution Gate │ │ Audit Trail │ └──────────┬──────────┘ │ ▼ ┌─────────────────────┐ │ External System │ │ / Action Adapter │ └─────────────────────┘
A simplified governed chain can be represented as:
Evidence E1 │ ▼ Fact F1 │ ▼ Derived Rule P1 │ ▼ Decision D1 │ ▼ Action A1
A change to E1 can therefore affect downstream state.
SC-SMT is intended to identify that impact and trigger the appropriate governance response.
A successful lifecycle may look like:
SYSTEM SEEDED ↓ EVIDENCE CHANGED ↓ DECISION REVALIDATION REQUIRED ↓ ACTION HOLD ↓ EVIDENCE VERIFIED ↓ DECISION REVALIDATED ↓ ACTION AUTHORIZED ↓ ACTION EXECUTING ↓ ACTION EXECUTED
A failed revalidation may instead produce:
EVIDENCE CHANGED ↓ DECISION REVALIDATION REQUIRED ↓ ACTION HOLD ↓ DECISION REVALIDATION FAILED ↓ ACTION HOLD
SC-SMT is being developed around several principles.
Consequential actions should depend on verified and current evidence.
Changes to evidence should propagate through registered dependencies.
The system should distinguish between permission, prohibition, and unresolved state.
ALLOW BLOCK HOLD
An authorization should be associated with the exact governed state under which it was created.
The system should perform a final state check immediately before an external action is committed.
Governance transitions should be reconstructable from the audit history.
Missing, conflicting, expired, or insufficiently verified evidence should not silently result in authorization.
SC-SMT is currently a product MVP / research-derived prototype.
The goal at this stage is to validate the mechanism and product workflow.
It should not yet be considered a production safety or compliance platform.
The current external action adapter is simulated.
Production implementation would require additional work around:
Completed / implemented:
Evidence Dependency Tracking Decision Revalidation Authorization Execution Gate Audit Trail
Current focus:
Expiry Old Authorization Reuse Action Parameter Tampering Duplicate Execution Missing Evidence Conflicting Evidence Unrelated Evidence Change
Planned:
Impact Map Dependency Blast Radius Affected Decision View Affected Action View Revalidation Queue Governance Dashboard
Potential future integrations:
ERP Procurement HR Compliance Identity Financial Systems AI Decision Engines Workflow Platforms
Planned areas:
Security RBAC Multi-tenancy Connector Authentication Durable Execution Observability Recovery Scalability Compliance
SC-SMT/ │ ├── server.js │ ├── public/ │ ├── index.html │ ├── app.js │ └── styles.css │ ├── test/ │ └── product.test.js │ ├── data/ │ └── .gitkeep │ ├── PRODUCT_BEHAVIORAL_SPEC_v0.2.md ├── data-model.json ├── package.json ├── Dockerfile ├── README.md └── .gitignore
Install and run with Node.js.
npm install npm start
The application exposes the local demonstration UI.
The current product demo uses a simulated external action adapter.
Current status: Active development
SC-SMT has progressed from a research concept into a working product-oriented MVP.
The current priority is to validate governance behavior under changing and adversarial conditions before expanding the product surface.
No open-source license is currently applied.
SC-SMT is currently maintained as a private product/research project.
SC-SMT
Working product description:
AI and automated-decision governance for changing knowledge and evidence.
Product promise:
AI systems that remain reliable when knowledge changes.
---
# 2. `PRODUCT_OVERVIEW.md`
```markdown
# SC-SMT Product Overview
## 1. Product Name
**SC-SMT**
### Product Promise
> AI systems that remain reliable when knowledge changes.
### Product Category
AI / Automated Decision Governance
---
# 2. Product Problem
AI systems and automated business systems make decisions using evidence available at a particular point in time.
That evidence can later change.
For example:
```text
Vendor qualification expires
Employee certification expires
Contract changes
Policy changes
Compliance status changes
Authorization changes
Pricing changes
A previously valid decision can therefore become stale.
The core problem is:
How does a system determine what existing decisions and actions are affected when the evidence behind them changes?
SC-SMT introduces a governance layer between evidence changes and consequential actions.
The system:
Evidence ↓ Evidence Evaluation ↓ Change Detection ↓ Dependency Closure ↓ Affected Decision Identification ↓ Decision Revalidation ↓ Authorization ↓ Execution-Time Validation ↓ External Action ↓ Audit Trail
All required governance conditions are satisfied.
The exact action may proceed through the execution gateway.
A policy or governance rule explicitly prohibits the action.
The action must not proceed.
The evidence, dependency state, verification, or revalidation is incomplete or unresolved.
The action must remain stopped.
Qualification VALID ↓ Purchase Decision CURRENT ↓ Purchase Action AUTHORIZED
Qualification expires:
Qualification EXPIRED ↓ Decision REVALIDATION_REQUIRED ↓ Purchase Action HOLD
New qualification arrives:
New Qualification VERIFIED ↓ Decision still requires explicit revalidation
Revalidation succeeds:
Decision CURRENT ↓ Authorization ↓ Execution-Time Validation ↓ Purchase Submitted
A key SC-SMT principle is:
New evidence should not silently make an old decision valid again.
The new evidence must pass the required verification and governance checks.
The dependent decision must be revalidated before the action becomes executable again.
SC-SMT treats authorization as a state-bound object.
Conceptually:
Authorization │ ├── Decision ├── Evidence Version ├── Policy Version └── Action Parameters
Changing any governed component can invalidate the authorization.
Execution should not rely only on an earlier authorization event.
Immediately before the external action is committed:
Authorization Check ↓ Decision State Check ↓ Evidence Binding Check ↓ Action Parameter Check ↓ Governance Check ↓ External Execution
This is intended to prevent stale authorization from being reused.
The product currently governs:
The system does not claim to automatically understand every dependency in an arbitrary external system.
Where required evidence is missing or dependency processing is incomplete, the intended behavior is to move to HOLD rather than guess.
The MVP uses a purchase approval scenario.
Action:
SUBMIT_PURCHASE_ORDER
Decision:
D-104
Action:
A-2207
External target:
SIMULATED_PROCUREMENT_SYSTEM
The external adapter is intentionally simulated at this stage.
The long-term goal is to provide a reusable governance layer for AI and automated decision systems that need to operate safely as underlying evidence changes.
Potential use areas include:
Procurement Finance Healthcare Compliance HR Identity Risk Enterprise AI Automated Approval Workflow Automation
These are potential application areas, not current production integrations.
---
# 3. `WORKFLOW.md`
```markdown
# SC-SMT Workflow
## End-to-End Governance Workflow
SC-SMT governs the relationship between changing evidence and downstream automated actions.
---
## 1. Evidence Registration
Evidence enters the system.
Example:
```text
Vendor Qualification
Status = VALID
Source = Verified Vendor System
Version = EV-005
Evidence is stored as a versioned record.
The system determines whether the evidence can be treated as verified and authoritative.
Conceptually:
RECEIVED ↓ VERIFIED ↓ AUTHORITATIVE
The product distinguishes between evidence merely being received and evidence being trusted for governance.
A decision is linked to the evidence required for that decision.
Example:
vendor.qualification.status ↓ D-104 Purchase Approval ↓ A-2207 Submit PO
Evidence can change because of:
Expiration Correction Replacement Supersession Conflict Policy Revision Time Change Authority Change
Example:
EV-005 VALID ↓ expires EV-006 EXPIRED
SC-SMT determines which registered objects depend on the changed evidence.
Example:
EV-006 ↓ D-104 ↓ A-2207
The action becomes part of the governance impact chain.
The previous decision can no longer automatically remain current.
Example:
Decision D-104 CURRENT
becomes:
Decision D-104 REVALIDATION_REQUIRED
A dependent action is prevented from proceeding while its governing decision is unresolved.
A-2207 HOLD
New or corrected evidence is verified.
The decision is explicitly re-evaluated.
Possible outcomes:
CURRENT BLOCKED HOLD
When the decision becomes current, an authorization may be created.
The authorization binds to the relevant state.
Example:
Decision = D-104 Evidence = EV-007 Policy = P-v1 Action Hash = ...
Before external execution:
Is authorization active? Is decision current? Are evidence bindings unchanged? Is policy unchanged? Are action parameters unchanged? Are governance conditions satisfied?
All required checks must pass.
Only after the gateway accepts the authorization can the external action proceed.
Current MVP:
SIMULATED_PROCUREMENT_SYSTEM
Future production adapters would require their own failure recovery and idempotency contracts.
Every major transition is recorded.
Example:
EVIDENCE CHANGED DECISION REVALIDATION REQUIRED ACTION HOLD EVIDENCE VERIFIED DECISION REVALIDATED ACTION AUTHORIZED ACTION EXECUTING ACTION EXECUTED
This provides a traceable governance history.
---
# 4. `ARCHITECTURE.md`
```markdown
# SC-SMT Architecture
## High-Level Architecture
```text
┌───────────────────────────────┐
│ AI / Business Decision System │
└───────────────┬───────────────┘
│
▼
┌───────────────────────────────────────────┐
│ SC-SMT │
│ │
│ Evidence Registry │
│ ↓ │
│ State / Validity Evaluation │
│ ↓ │
│ Dependency Engine │
│ ↓ │
│ Decision Governance │
│ ↓ │
│ Revalidation │
│ ↓ │
│ Authorization │
│ ↓ │
│ Execution Gate │
│ ↓ │
│ Audit Trail │
└────────────────┬──────────────────────────┘
│
▼
┌───────────────────────────────┐
│ External System / Action │
│ Adapter │
└───────────────────────────────┘
Maintains versioned evidence records.
Tracks:
Maintains relationships between:
Evidence Facts Decisions Actions
Used to identify downstream impact when upstream evidence changes.
Determines whether an existing decision remains current.
Possible states include:
CURRENT REVALIDATION_REQUIRED BLOCKED
Creates an authorization bound to:
Evidence Decision Policy Action Parameters
Performs the final validation immediately before an external action is committed.
The gateway is intended to be the last governance control before consequential execution.
Stores governance events with:
Actor Reason Object Context Timestamp
Current MVP persistence:
SQLite
Primary entities include:
sources evidence dependencies decisions actions authorizations audit_events
The current external adapter is simulated.
This allows the governance mechanism to be validated without causing real-world side effects.
Production adapters will require:
---
# 5. `DEVELOPMENT_STATUS.md`
```markdown
# SC-SMT Development Status
## Current Version
SC-SMT Product MVP v0.2
---
# Completed
### Core Governance
- [x] Evidence registration
- [x] Evidence versioning
- [x] Evidence validity
- [x] Evidence verification state
- [x] Dependency registration
- [x] Dependency cycle rejection
- [x] Decision registration
- [x] Decision evidence binding
- [x] Policy version/hash binding
- [x] Decision revalidation
- [x] Action authorization
- [x] Action parameter binding
- [x] Execution-time validation
- [x] Idempotency handling
- [x] Audit events
- [x] Expiry handling
---
# Validated Manually
## Qualification Expiry
Validated behavior:
```text
EVIDENCE CHANGED
↓
DECISION REVALIDATION REQUIRED
↓
ACTION HOLD
Attempted revalidation with invalid evidence produces:
DECISION REVALIDATION FAILED ↓ ACTION HOLD
After verified replacement evidence:
EVIDENCE VERIFIED ↓ DECISION REVALIDATED ↓ ACTION AUTHORIZED ↓ ACTION EXECUTING ↓ ACTION EXECUTED
The next validation scenarios are:
The external execution system is currently simulated.
The product should not yet be treated as a production safety, compliance, or autonomous execution platform.
Show:
Changed Evidence ↓ Affected Dependencies ↓ Affected Decisions ↓ Affected Actions ↓ Required Revalidation
Future dashboard concepts:
Current Decisions Revalidation Required Blocked Decisions Held Actions Evidence Changes Affected Actions Recent Governance Events
Future areas:
Authentication RBAC Multi-Tenancy Connector Security Secrets Management Durable Events Execution Recovery Observability Monitoring Backup / Recovery Security Testing Scalability Compliance
---
# 6. `PRODUCT_POSITIONING.md`
```markdown
# SC-SMT Product Positioning
## One-Line Description
> SC-SMT is a governance layer that keeps AI and automated decisions aligned with changing evidence.
---
## Product Promise
> AI systems that remain reliable when knowledge changes.
---
## Core Question
Traditional AI decision systems ask:
> Given the current information, what should the system decide?
SC-SMT focuses on a different question:
> When the evidence behind an existing decision changes, what becomes affected, what must be revalidated, and can the dependent action still execute?
---
## Product Model
```text
Knowledge Changes
↓
Impact Detection
↓
Decision Revalidation
↓
Action Governance
↓
Execution Control
SC-SMT is centered on change propagation and governance, rather than only generating a new decision from the latest state.
The product attempts to preserve the relationship between:
Evidence Decision Dependency Authorization Action
when the evidence changes.
Proposed category:
AI Knowledge & Action Governance
Alternative description:
Evidence-Driven Decision Governance
Organizations increasingly use AI and automation to make or execute decisions.
The underlying evidence may change after a decision is made.
SC-SMT is designed to provide a governance layer that identifies affected decisions and prevents stale actions from proceeding without revalidation.
Potential areas include:
These represent potential future application areas rather than existing production integrations.