Governed foundation
- Domain objects
- Schemas + canonical hashing
- Persistence
- Lifecycle transitions
- Receipts
Release Two public overview
Progression is not consequence.
SIW separates knowledge progression from reintegration and binding. The architecture can accept a branch finding while deliberately withholding merge, activation, binding, or consequence.
Knowledge progression
- Protection evaluation
- Activation
- Bounded branches
- Branch findings
- Inspect / accept / reject
- Standing revalidation
Controlled convergence
- Selective merge proposal
- Revalidation
- Governed merge application
- Provenance preservation
Binding + proof
- Composition / binding
- Independent verification
- Authority handling
- Adversarial hardening
- Release closure
Acceptance is not authority to bind.
The public architecture should make the boundary visible rather than compressing accepted knowledge and consequential execution into one state.
Human authority
Machine-readable structure. Human-readable standing.
SIW is not presented as a machine-only substrate. Human inquiry, inspection, rejection, acceptance, intervention, correction, and authority remain first-class parts of the experience.
Inspect
Interpretation, assumptions, branch state, and evidence can be surfaced without exposing every internal mechanism by default.
Decide
Acceptance and rejection remain explicit acts with preserved lineage rather than silent model-state mutation.
Revalidate
Prior permission does not automatically establish present standing when conditions, purpose, route, or target have changed.
Architecture lineage
SIW sits downstream of a broader Genesis AiX governance lineage.
The interface prototype is only one part of the history. The governance substrate also developed through LifeStack, GPM/GDE, and WEDGE.
Broader governance
Policy, provenance, trust, security, knowledge, and governed infrastructure.
Governed continuity
Memory, actor/authority scope, admissibility, review, persistence, provenance, and receipts.
Consequence boundary
Current standing, route, executor, no-bind/refusal, replay, substitution, and verification.
Governed inquiry
Inspection, activation, bounded branching, selective merge, composition, binding, and evidence.
Architecture inheritance, not mandatory coupling.
Product names do not become runtime prerequisites. SIW can implement required controls locally or consume compatible services.
Independent review boundary · Build 12.6
What the public architecture can claim — and what still requires implementation evidence.
The August 18 review sharpened several load-bearing boundaries. Build 12.6 makes those limitations visible instead of letting architecture language imply an implementation property that has not been demonstrated.
Capability vs. authority
Separating a decision from authority is strongest when the executor derives its ability to produce the protected consequence from the bind. If an executor already holds ambient credentials, a permission check can still be bypassed. The public site does not claim this implementation question is universally resolved.
Route closure
WEDGE can refuse on a declared governed route. Global route closure requires a deployment-specific route inventory, credential model and residual-path disclosure; refusal on one route does not prove that no alternate route exists.
Irreversibility horizon
The architecture can revalidate before bind. Once an external effect becomes irreversible, later refusal cannot undo it. Proof profiles should therefore declare the consequence class, bind-to-effect interval and irreversibility horizon.
Exact consequence
“Exact” means an explicitly declared finite set of decision-relevant attributes for that consequence class — not a hash of the entire world state.
Material substitution
Materiality must be adjudicated against the declared runtime attribute set and governing rules. It is not left to an unspecified model judgment.
Evidence and standing
Evidence may ground a standing determination when it is fresh, authoritative and scope-matched. A prior receipt about authority is not automatically present authority.
External knowledge boundary · explanatory, not a build authorization
How enterprise knowledge can connect to SIW.
SIW does not need to own the knowledge resource. It can provide a governed view into an external knowledge source. Genesis AiX keeps four things separate: workflow, knowledge resource, governed context, and the intelligence/model layer.
Path 1 · Direct SIW binding
Bind an enterprise source directly
An enterprise knowledge source may be made available directly to SIW through an appropriate adapter. Illustrative sources may include SharePoint, Google Drive, Confluence, document repositories, databases, APIs, knowledge graphs, and uploaded files.
These examples illustrate architecture only. This is not a claim that every listed connector is already implemented.
Path 2 · Workflow-aware binding
Through Workflow Composer
When an enterprise imports or models a workflow in Workflow Composer, Composer may identify or propose the knowledge resources required by specific workflow steps, decisions, roles, exception paths, and evidence requirements — producing a candidate Knowledge Binding Manifest associating workflow locations with relevant knowledge resources.
When that workflow context is opened in SIW, SIW can provide a governed view into the appropriate knowledge without requiring that knowledge to become part of SIW itself.
| Workflow location | Candidate knowledge binding |
|---|---|
| Vendor Review | Vendor Master + Supplier Policy |
| Compliance Check | Compliance Repository + Contract Record |
| Approval | Delegation-of-Authority Matrix + Current Request |
Knowledge Nugget · governance distinctions
Connected is not selected. Selected is not activated.
Connected ≠ selected. Selected ≠ activated. Retrieved ≠ admitted. Model output ≠ governed knowledge. A Knowledge Binding Manifest proposes candidate associations only — it does not itself select, activate, or admit anything.
Composer defines where knowledge is needed. SIW provides the governed view into that knowledge. Genesis Gateway provides access to model intelligence when reasoning is required.
Enterprise Knowledge Sources
SharePoint, Drive, Confluence, repositories, databases, APIs, knowledge graphs, uploads
→
Knowledge Adapters
Illustrative — not all connectors implemented
→
Composer / Knowledge Binding Manifest
Candidate workflow-to-knowledge associations
→
SIW Three-Panel
Governed view, not ownership
→
Genesis Gateway
Admissibility + disclosure boundary
→
Authorized Model / Provider
When reasoning is required
SIW Three-Panel is not the Canon. Canon is one governed knowledge source/binding that SIW can view. The same SIW core may be used with no Canon binding, with Canon, with enterprise knowledge, with other authorized knowledge sources, or with explicitly configured combinations of those — these are configurations of one SIW core, not separate SIW codebases.
Not authorized by this nugget: building new connectors, claiming unimplemented integrations are operational, changing Canon standing, changing SIW runtime semantics, automatic knowledge activation, or treating retrieval as Canon admission.
External intelligence boundary
Genesis API Middleware / Model Gateway
SIW is designed as the governed application layer between the user and external intelligence or knowledge environments. The gateway remains provider-neutral so frontier labs, open-weight models, enterprise/private models, and specialized knowledge systems can participate without any provider becoming the source of SIW authority.
Before transfer, SIW determines what context and data are admissible for the selected destination. Returned material re-enters SIW with provider identity, provenance, evidence, and governance state preserved.
User
Intent
→
SIW
Inquiry assembly + standing
→
Genesis Model Gateway
Admissibility + disclosure boundary
→
External Intelligence
Model or knowledge environment
→
Governed Return
Evidence + provenance
Current team-review standing:
Team Review Candidate 1 demonstrates the governed SIW
application. Live model connectivity through this gateway is
the next operational integration step and is not claimed as
implemented in the frozen candidate.