Policy Engine & Data Governance

SDL treats data policy as code — policies are defined in code, versioned alongside the platform, tested through CI/CD pipelines, and deployed as part of every release. Rather than relying on external policy administration points, the platform embeds governance directly into the data layer so that every query, every replication event, and every cross-domain transfer is subject to the same enforceable rules.

Row-Level and Column-Level Obfuscation

The policy engine supports fine-grained obfuscation at both the row and column level:

Row-level filtering: Entire records are filtered based on the requesting user’s clearance level and need-to-know designations. If a user lacks authorization for a particular record’s classification or compartment, that record is excluded from query results entirely.
Column-level obfuscation: Individual fields within a record can be redacted, masked, or generalized based on the data sensitivity of that field. For example, a user with appropriate clearance may see the full entity record, while a user at a lower authorization level sees the same record with sensitive fields replaced by masked values or removed altogether.

All obfuscation is applied at query time. The underlying data remains unchanged in storage, preserving the full-fidelity record for users who hold the required authorization.

Node-Local Policy Enforcement

Policies travel with the deployment. Each SDL node carries the full set of applicable policies and evaluates them locally against its own data and the requesting user’s context.

No reach-back to a central policy server is required for policy evaluation.
Nodes operate autonomously, enforcing governance even in disconnected or degraded network conditions.
Policy updates propagate through the mesh alongside data, ensuring that every node converges on the current policy set without requiring a dedicated control channel.

This architecture means that policy enforcement is not a single point of failure and that edge deployments maintain the same governance guarantees as cloud-hosted instances.

Classification Markings

Every entity and every task in SDL carries a complete security marking object. The marking system supports the full range of classification and dissemination controls:

Marking Type	Examples
Classification level	UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP SECRET
Dissemination controls	NOFORN, REL TO, FOUO, and other standard controls
SCI/SAP compartments	Compartmented access designations as required by the data source
Releasability markings	Nationality-based release designations (e.g., REL TO USA, FVEY)

Marking Type

Examples

Classification level

UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP SECRET

Dissemination controls

NOFORN, REL TO, FOUO, and other standard controls

SCI/SAP compartments

Compartmented access designations as required by the data source

Releasability markings

Nationality-based release designations (e.g., REL TO USA, FVEY)

These markings are not metadata annotations applied after the fact. They are integral to the entity data model and are evaluated by the policy engine at every access point.

Multi-Enclave Policy Evaluation

In multi-enclave deployments, the policy engine evaluates security context across classification boundaries:

FVEY, NOFORN, and REL TO evaluation — Policies determine whether a given entity’s releasability markings permit transfer to the requesting enclave or user.
Source and destination enclave security levels — The engine evaluates the classification ceiling of both the originating and receiving enclaves before permitting data flow.
Cross-domain transfer decisions — Each entity’s marking is compared against the destination enclave’s authorization. Transfer is permitted only when the entity marking falls within the destination’s allowed classification range.
Automatic downgrade and redaction — Where policy permits, entities can be automatically downgraded or have sensitive fields redacted to meet the destination enclave’s classification ceiling.

Integration with Platform Capabilities

The policy engine is not a standalone component. It integrates directly with the core platform capabilities:

Query: Policies enforce row-level and column-level filtering at query execution time. Users see only the data they are authorized to access, with no additional application logic required.
Cross-domain: Policies govern what data flows between classification boundaries. Every cross-domain transfer decision is evaluated against the entity’s marking and the destination enclave’s authorization.
Streaming: Security markings are propagated through transformation pipelines. As data moves through enrichment and fusion stages, the resulting entities inherit or receive updated markings based on the source data and the transformation rules.