Community
Email, best effort
We read everything and answer as fast as we can, usually within a couple of business days. The docs and status page are your fastest path while you are evaluating.
Fibric senses, reasons, and acts on the things you run. When that loop is doing real work, you want answers fast and you want a human on the other end. Start with the docs below, check live status, or write to a person who can actually help.
The docs cover the envelope, the propose-and-dispose executor, connectors, and governance. If something is unclear, that is on us. Tell us and we will fix the page.
Core concepts, connectors, the Connector SDK, governance, and the full API reference. The single source of truth for how Fibric works.
Open the docs → BuildConnect a system, set an intent, and watch the first governed action run end to end. About ten minutes from nothing to a receipt you can read.
Run the quickstart → CheckLive operational status for the platform, connectors, and the products built on it. Check here first if something looks slow or stuck.
View live status →If the docs do not cover it, write to us. A real person reads every message and replies. We would rather you reach out early than restart a loop you were unsure about.
A good report gets a faster, better answer. The more we can see of what you saw, the less back-and-forth it takes. Idempotency keys and receipts make most problems reproducible, so if you have them, send them.
We are in early access, so we will tell you the truth rather than promise a number we cannot hold to every day. These are the windows we aim for. See availability for the operational detail and pricing for what each plan includes.
Email, best effort
We read everything and answer as fast as we can, usually within a couple of business days. The docs and status page are your fastest path while you are evaluating.
Email, next business day
A named queue and a real human owner per thread. We aim to reply within one business day, and sooner for anything blocking a live, governed action.
Direct line, same day
For larger deployments we set up a direct channel and same-day handling for anything affecting production. We size this to what you run, not a tier on a chart.
These are targets, not contractual guarantees. We would rather under-promise here and over-deliver in your inbox. A formal availability commitment is part of how we scope larger deployments.
Trust fails closed, not open. That holds for how we handle the security of the platform too. If you have found a vulnerability, we want to hear from you, and we will work the report in good faith.
How we govern action, wall off tenant data, write receipts, and fail closed when a policy is unsure. The whole trust spine, written plainly.
Read the trust page →How to report a security issue, what we ask of you while we investigate, and what you can expect from us in return. Please do not post issues publicly first.
Disclosure policy →Short, honest answers. If yours is not here, the docs go deeper, and support@fibric.io goes deeper still.
Fibric is in early access. Start from onboarding: you connect a system, set an intent, and go live in your own walled-off tenant. There is no waiting room once you start. If you are evaluating for a larger deployment and want a hand, write to support@fibric.io and a person will get you set up.
The platform is free. You pay for the integrations and add-ons you actually run, so the bill tracks usage rather than seats. Most teams stay modest because you only turn on the connectors and operators you need. The full breakdown, including what each plan includes, lives on pricing.
In your tenant, walled off from every other tenant at the data layer. Every signal becomes one canonical event envelope stamped with your tenant, and every action writes an attributable, reversible receipt you can read. Fibric uses only real, governed data. A placeholder can never masquerade as a real metric. The full handling and isolation detail is on the trust page.
We are honest about this in early access. The response posture above is what we aim for by plan, and live operational status is always on status and availability. A formal availability commitment is something we scope with you for larger, production deployments rather than print a single number we cannot hold to for everyone. Ask support@fibric.io and we will be straight with you.
That is config, not a rewrite. In Fibric a capability points to a connector through indirection, and connectors are built on MCP, so swapping one system for another is a setting change rather than rebuilt plumbing. Connectors in the docs walks through it, and support can help you plan a migration if it is a large one.
The fastest way to understand Fibric is to run one governed action end to end. Start from onboarding, and reach out the moment you have a question.