The framework operates across three layers. Each layer has a distinct function and can evolve independently.
┌─────────────────────────────────────┐
│ Layer 3: Deliberation │
│ Multi-perspective council │
│ Procedures with HIL triggers │
├─────────────────────────────────────┤
│ Layer 2: Intelligence │
│ Semantic routing │
│ Interpretation generation │
├─────────────────────────────────────┤
│ Layer 1: Data │
│ Source integration │
│ Structured pipeline │
└─────────────────────────────────────┘
Raw data from source systems flows through a structured pipeline that produces a clean, consistent management view.
The pipeline has three stages:
Stage 1 — Raw extraction Data arrives from source systems unchanged. No business logic applied. Immutable audit trail preserved.
Stage 2 — Standardization Schemas normalized. Relationships established. Common vocabulary applied across sources. This stage is largely reusable across organizations.
Stage 3 — Management view Configured per organizational context and stage. The same underlying data produces different views depending on what the organization is trying to understand — survival, growth, profitability, or something else. This is the only stage that requires customization.
The pipeline is designed so that customization is declarative, not code. You configure the management view; the infrastructure handles the rest.
Problems are matched to perspectives through semantic similarity. The input — a problem statement — is compared against the documented knowledge of each perspective. The closest matches are activated, weighted by:
- Domain relevance
- Thinking style fit
- Relationship to the decision-maker
- Contribution history
- Recency of activation
The result is a roster of perspectives — not randomly assembled, but matched to the specific problem at hand.
The roster is not optimized for agreement. Centripetal perspectives (those that converge toward consensus) are balanced with centrifugal perspectives (those that challenge and expand). A deliberation that produces only convergence has failed at its core function.
When structured data needs to become a human-readable output — a report, a diagnosis, an answer — the system generates a draft through the intelligence layer. The draft is not the final output. It enters a human validation workflow before delivery.
This is a design principle, not a limitation: high-stakes outputs require human judgment at the last mile.
Perspectives are organized into chambers with distinct governance roles:
Governance chamber — always present
Permanent overlay on every session
Maintains continuity, accountability, and focus
Domain chambers — activated by semantic routing
Organized by knowledge cluster
Matched to the specific problem
High-risk chamber — sovereign-activated only
Perspectives that destabilize before they clarify
Mandatory governance voice after every intervention
Each perspective in the council has documented:
- Primary bias — what it sees first and amplifies
- Suppressions — what it systematically underweights
- Blind spot — what it structurally cannot see
- Epistemic nature — whether it generates perspectives, executes processes, delimits fields, or performs systemic functions
This documentation is not optional. A perspective without documented bias is not a perspective — it is an oracle. The framework explicitly rejects oracle-style responses.
Every element in the system carries traceable origin:
- Persistent identifier — stable across substrates and time
- Change history — every reclassification is logged with type, reason, session, and author
- Epistemic context — non-obvious classification choices are explicitly declared
- Vocabulary mapping — perspectives map to W3C SKOS standards, enabling RDF export and external interoperability
The distinction between revision and paradigm shift is preserved in the change history. When a knowledge map is restructured, the record shows not just what changed but why the previous structure became incommensurable with the new one.
The framework has explicit, declared human-in-the-loop triggers:
Always human: Final decisions. Structural amendments. Perspective admission and exclusion.
System handles autonomously: Semantic routing. Session logging. Cross-domain activation.
Configurable per procedure: Report validation. Agent execution. Cross-domain deliberation triggers.
Human oversight is not treated as a failure mode. It is treated as a design requirement. The trajectory of the system is toward humans governing the system — not toward eliminating human judgment from outputs.
The architecture is designed to evolve from a deliberative system to an executing one. Perspectives link to procedures. Procedures carry declared scope, declared out-of-scope, and explicit human escalation triggers.
Procedure types:
deliberative → judgment-dependent, always HIL
operational → deterministic, HIL by exception
hybrid → begins operational, escalates on edge cases
This is not the current state. It is the direction the architecture is designed to support.
Five handoff points exist between layers. Each has a sensor that detects misalignment before it becomes a failure:
Classification → Retrieval
Is the semantic position consistent with actual usage?
Retrieval → Execution
Does the retrieved perspective have a linked procedure?
Execution → Governance
Is the human escalation trigger explicitly declared?
Governance → Substrate
Is the persistent identifier stable across systems?
Substrate → Classification
Is the knowledge synchronized across substrates?
Misalignment at any handoff is surfaced, not silenced.
Polic Framework — Architecture v1.1 — Lucas Santos — 2026