Decide what an operator may do.

Set the permissions. Check every action.

A plan needs permission

The executor checks each plan against the customer’s policy. Unsupported actions and failed checks stop execution.

The generalized kernel is the reference contract. Live product capabilities depend on the deployed action inventory.

Controls with defined limits

Tenant scope: Keep data, credentials, and permissions with their customer.
Action scope: Set allowed operations, limits, and approval requirements.
Concurrent work: Single-flight controls coordinate attempts on the same entity.
Retries: Identify repeat requests. Reconcile uncertain results with the source system.
Action records: Record requests, decisions, and reported outcomes. Verify physical results separately.

Review the operating conditions

Define system ownership, permitted changes, and how to handle uncertain results. Equipment actions also require site limits and local authority.

Read the governance reference

The trust spine

Four objectives for evaluating a deployment.

Live BearScope applies source and tenant controls in its application BFF. The generalized kernel is the reference contract used to evaluate managed early-access deployments.

Real data only No placeholders

Live BearScope customer surfaces distinguish governed source data from fallback or missing states. A displayed metric should identify its source; missing data should remain missing rather than appear as a customer fact.

/ Governed values are tagged with their source; fallback content is labelled as fallback.
/ Governed live paths are designed to use real, source-tagged data while keeping seed and mock values out of customer facts.
/ Missing data surfaces as missing, with an honest empty state, not a confident fabrication.
/ This is a data-quality requirement, not a paid feature.

Enabled actions pass a check Fail-closed objective

The reference architecture separates model proposals from dispatch and applies configured checks to supported plan steps. A managed deployment must validate that the enabled capability can be blocked before dispatch and define what happens when policy or evidence is insufficient.

/ The target path has the model emit a structured execution plan rather than hold direct connector authority.
/ A deterministic check evaluates enabled plan steps against configured rules before dispatch.
/ Single-flight per entity + idempotency keys are designed to collapse retries and suppress duplicate effects.
/ Steps that cannot meet the configured evidence or policy threshold should be refused or sent for review.

Tenant-scoped access Data-layer checks

The live BearScope data path sets tenant context before governed queries run, and row-level security limits tenant-owned tables at the database layer rather than relying only on a UI filter.

/ Tenant context is applied to governed requests and tenant-owned data; isolation is enforced at the data layer.
/ Row-level security scopes governed BearScope queries on tenant-owned tables to the calling tenant.
/ Tenant scope is treated as an authorization boundary and tested as such.
/ Export and retention requirements are scoped in the customer agreement.

Supported action records Reviewable where instrumented

Where execution is enabled, the supported path records what it sensed, what was proposed, what policy allowed, and what the connected system reported as the outcome.

/ Supported actions write an execution record: the trigger, plan, policy check, and reported outcome.
/ Where the path supports it, a record can link the canonical event to the proposal and reported action outcome.
/ The record preserves the evidence and proposal used for review.
/ Retention is set during onboarding and confirmed in the customer agreement.

How an action is governed

The model proposes. A deterministic check approves it or blocks it.

This is the reference action path. It reduces risk through explicit policy, scoped authority, duplicate suppression, and a recorded outcome; it does not replace independent safeguards or human responsibility.

01 / Sense

Read real data

The reference path maps supported source records to a canonical event with tenant and provenance fields. Missing and fallback states must remain distinct.

02 / Propose

Model plans

The model proposes a structured execution plan. On the reference path, application credentials and policy checks control dispatch.

03 / Vet

Your rules decide

A deterministic check measures the plan against the limits you set and can block a step. Idempotency keys and single-flight controls are used to suppress duplicate effects on retry.

04 / Act + receipt

Do, and record

Approved steps run through the connected system's supported path and write an execution record or a blocked-action record.

These controls are designed to prevent the 657-message failure mode: single-flight limits concurrent work per entity, idempotency keys collapse known retries, and policy can stop a plan before dispatch. End-to-end behavior still depends on each downstream system honoring the contract.

Security posture

Current controls and target objectives, with their boundaries.

Live BearScope controls are identified as such. Generalized-platform and enterprise items are deployment objectives or contractual options until validated in writing.

Encryption

Protected in transit and at rest

✓ Live BearScope uses managed HTTPS and AWS encryption controls on its supported path.
✓ Managed deployments must validate encryption in transit, at rest, and at each connector boundary.
✓ Connector credentials must use an approved secret store and must not be committed to code.
✓ Customer-managed keys or region commitments are contractual options, not public defaults.

Isolation

Walls enforced at the data layer

✓ Live BearScope sets tenant context and uses row-level security on governed tenant-owned tables.
✓ Managed deployments must propagate verified tenant context through each supported request path.
✓ Least privilege and tenant-scoped secrets are control requirements, verified per deployment.
✓ A catalog listing alone does not establish a deployed isolation boundary.

Audit

Supported paths on the record

✓ Supported BearScope actions and material access events preserve attributable application records where instrumented.
✓ A record states what the Fibric boundary observed; it is not proof of external truth.
✓ Model output and evidence can be retained for review where the product path supports it; reasoning is not universally replayable.
✓ Export and retention terms are validated and agreed per managed deployment.

Access & identity

Who can do what, controlled

✓ Live BearScope uses managed identity; connector tokens are scoped on supported integrations.
✓ Policy and approval gates are required before supported high-impact writes.
✓ SSO, SAML, SCIM, and provisioning commitments require a written enterprise scope.
✓ No public generalized-platform identity or administration surface is offered today.

Resilience

Controls for failure and load

✓ Single-flight + idempotency reduce concurrency and duplicate-action risk.
✓ The reference policy objective under uncertainty is fail-closed; each managed path must verify that behavior.
✓ Swap-seams are a reference-architecture objective; each live dependency still needs an operational runbook.
✓ Deployment-specific limits can bound action volume; no public metering service is implied.

Data handling

We hold the minimum, plainly

✓ Data minimization, model-provider use, and connector scope are documented per managed deployment.
✓ Training, retention, deletion, and legal-hold terms are governed by the applicable agreement and DPA.
✓ No public plan creates a default retention or deletion commitment.
✓ The current named sub-processor list is provided with the managed agreement.

Sub-processors

Who we rely on, and for what.

These are public provider categories, not a complete current list. The named providers, functions, regions, and notice process that apply to a customer are set out in the applicable managed agreement or data-processing schedule.

Sub-processor	Purpose	Data scope
Cloud infrastructure	Compute, managed database, storage, and networking for the platform.	Scope, region, and tenant controls depend on the contracted production path.
Model provider	Hosted base model that powers reasoning over your operational picture.	Only where a named provider and governed context are included in the customer agreement.
Identity & auth	Authentication, session management, and enterprise SSO.	Identity data and service scope depend on the named provider and contracted path.
Managed connectors you authorize	A managed deployment reaches only systems and capabilities included in its approved connector scope.	Permissions and data scope must be validated for the supported connector and tenant.

Categories shown for clarity. Read the public summary or request the named schedule for your contracted service at privacy@fibric.io. Change notices and objection rights are contract-specific.

AI transparency & ethics

An agent you can hold accountable.

Autonomy without accountability is just risk. Here's how we keep Fibric's reasoning honest, bounded, and answerable to you.

The model does not hold dispatch authority on the supported path

Reasoning is a proposal, not a command. The target control path uses a deterministic check against configured rules before an enabled capability is dispatched; that separation is validated per managed deployment.

Supported actions leave reviewable evidence

Where instrumented, an action record can show what the Fibric boundary sensed, what was proposed, which policy cleared it, and what the connected system reported. It supports review without claiming perfect knowledge of downstream truth.

No fabricated confidence

Live customer surfaces distinguish source data, missing states, and fallback content. Model-generated analysis still requires review; the data policy is not a guarantee that a model cannot be wrong.

You set the boundaries

The customer agreement and deployment configuration define what an operator may propose, which actions need approval, and where the path should stop. Enforcement must be validated for each enabled connector and capability.

Your data isn't our training set

Customer Data is not used to train a shared model unless the customer expressly agrees in writing. Live BearScope applies tenant-scoped access controls to governed tenant-owned data; other managed paths require their own validation.

Bounded, not boundless

Managed deployments should enable only capabilities whose policy, concurrency, action-record, human-review, and recovery boundaries have been validated. Those controls reduce risk rather than eliminate it, and downstream-system behavior remains part of the result.

Questions about security

Questions about security.

Want our DPA, the named sub-processor list, or a security review for your team? Write to us.

Contact security → Read the governance reference

The short version: source-tagged BearScope data, tenant-scoped access, configured checks, and supported action records, with managed-deployment boundaries validated in writing.

Build with Fibric.

Request access