{ "revision": "v4-company-story", "description": "Shared public narrative for the human pages and Agent documents. Statements describe the platform model and intended control paths; they are not release certification.", "pages": [ { "path": "/company/", "title": "Why DriftGate exists", "intro": "Agentic work crossed from answering questions into using tools, accounts and business systems. DriftGate exists to make that work accountable without forcing every team into one model or runtime.", "sections": [ { "id": "company-origin", "kind": "editorial", "heading": "Work became agentic. Control stayed fragmented.", "body": [ "A useful agent may move among a coding client, a hosted workflow, a knowledge source and an external system. Each surface can carry its own tools, instructions, permissions and records. When a task fails or changes, the operator has to reconstruct which setup was active, whose authority applied and whether an outside effect happened.", "That problem can begin with one person working across devices and projects. It becomes a company problem when teams share agent infrastructure, delegate consequential actions and need to explain an outcome later. DriftGate's purpose is to connect environment, authority, action, evidence and improvement in one operating model." ] }, { "id": "company-belief", "kind": "statement", "heading": "Flexible intelligence needs explicit authority.", "body": [ "Models and runtimes can vary. The source of authority for a customer refund, production change or private data read cannot be inferred from a prompt alone. The governed request needs an actor, resource, operation, current scope and a decision at a boundary capable of affecting that operation.", "Evidence then has to distinguish the decision from the effect. An approval can expire or be revoked; an allowed request can time out after the provider acts; a trace can describe behavior without being able to stop it. Those differences shape the platform." ] }, { "id": "company-model", "kind": "sequence", "heading": "The work connects through a loop.", "items": [ { "title": "Gate the action", "body": "Check current identity, policy and approval before a consequential effect at a qualified boundary." }, { "title": "Understand the drift", "body": "Compare intended configuration and behavior with what is actually observed; investigate the divergence." }, { "title": "Keep the lesson", "body": "Test a candidate change independently, review it, release to a defined audience and retain rollback." } ], "body": [ "The loop serves a personal project, a shared team baseline and an organization-wide standard without converting a private lesson into shared authority by accident." ] }, { "id": "company-scope", "kind": "editorial", "heading": "A control plane around the work you already run.", "body": [ "DriftGate is designed to sit around existing coding harnesses and standalone agentic products, including voice, support, sales, finance and custom workflows. The planner, model and runtime can remain external. API and SDK paths express governed intent at the consequential operation; MCP and qualified ACP integrations are entry points, not automatic enforcement boundaries.", "The platform direction spans six control domains and reviewed learning. Each integration still needs its own authority, effect boundary and release qualification. A visible connection or website description alone does not establish that a control is running." ] }, { "id": "company-proof", "kind": "evidence", "heading": "Read the evidence for what it is.", "body": [ "The 24 workflows on this site use example data to explain control design. Two incident analyses discuss attributed public research and the control lessons it suggests. Neither is a DriftGate customer deployment or proof that DriftGate prevented the reported event.", "Release and integration behavior need qualification in the target environment; the availability page explains how to read platform scope and control modes." ] } ] }, { "path": "/", "title": "Control for agentic work", "intro": "From one person's AI setup to consequential company workflows, DriftGate connects approved environments, current authority, bounded actions, evidence and reviewed learning.", "sections": [ { "id": "home-company", "kind": "editorial", "heading": "Agents can be capable. The work still needs an owner.", "body": [ "An agent can cross tools, accounts and systems during a single task. Give that work a clear starting environment, a current permission boundary and a record of what actually happened. When the same failure recurs, turn the fix into a tested, reviewed improvement.", "Explore the platform as a connected operating model, then follow a workflow to see where the decision, effect and evidence belong." ] } ] }, { "path": "/platform/", "title": "The platform model", "intro": "One governance and learning control plane for agentic systems, from the approved setup to the observed outcome.", "sections": [ { "id": "platform-boundaries", "kind": "definitions", "heading": "Know what each control can claim.", "items": [ { "title": "Observe", "body": "Record what a qualified integration can see, including relevant configuration, decisions and outcomes." }, { "title": "Warn", "body": "Surface a mismatch or risk to the responsible operator before or after work, depending on the integration." }, { "title": "Require approval", "body": "Pause a qualified action and bind a reviewer's decision to the material request and current authority." }, { "title": "Enforce", "body": "Allow, deny or constrain an operation only where the integration owns a real pre-effect boundary." } ], "body": [ "These labels describe different capabilities. A trace is evidence, not a blocking control. A tool appearing in discovery is not authorization to invoke it." ] }, { "id": "platform-operating-model", "kind": "editorial", "heading": "One model, several kinds of change.", "body": [ "A configuration or skill update changes the environment an agent starts from. A permission or policy change changes what it may do now. A workflow or model change can alter behavior; a business-system response establishes whether a requested effect occurred. DriftGate relates these facts so the next decision and investigation use the right revision and identity.", "The same model applies to coding agents and independent agent products. The integration method follows the task: connect a supported client for environment governance, and place consequential operations behind a qualified API, SDK or adapter path." ] } ] }, { "path": "/services/", "title": "Platform service areas", "intro": "Bring approved environments, governed actions, evidence and reviewed improvements into one operating model. Start with the service area that answers your next task.", "sections": [ { "id": "services-start", "kind": "editorial", "heading": "Start with the work that matters.", "body": [ "A coding team may first need a repeatable project environment. A customer operations team may first need a controlled refund. A platform team may first need a clear inventory of workload identities and connected resources. Each is an entry point into the same governance model.", "Choose a concrete actor, resource and operation. Then identify which parts can be observed, which can be warned on and where an approval or enforcement decision can actually affect the result." ] }, { "id": "services-areas", "kind": "definitions", "heading": "Six connected control domains, with learning across them.", "items": [ { "title": "Environment & Tooling Management", "body": "Versioned profiles, skills, instructions and tool choices; verification of intended versus observed client state." }, { "title": "Identity, Access & Policy", "body": "People and workloads with distinct authority, scoped connections, approvals and current permission checks." }, { "title": "Runtime Governance & Execution Control", "body": "Qualified action gates, effect identities, limits, receipts and reconciliation when the provider outcome is unknown." }, { "title": "Observability, Audit & Assurance", "body": "Attributable records, observations, investigations and verification of the resulting state." }, { "title": "Lifecycle & Change Management", "body": "Reviewed releases, affected consumers, rotation, revocation and retirement." }, { "title": "Data & Context Governance", "body": "Source ownership, permission-aware retrieval, provenance, isolation and deliberate sharing." } ], "body": [ "Reviewed learning connects these domains: recurring friction can become a tested, approved change with a defined audience and rollback." ] }, { "id": "services-fit", "kind": "editorial", "heading": "Discuss adoption around a specific workflow.", "body": [ "Environment onboarding, integration planning, policy and approval design, and knowledge or context design can be scoped around your actual clients, accounts and business operations. Enterprise evaluations can also cover identity, deployment, retention and evidence requirements.", "Scope and delivery are agreed for your environment. A public capability description does not guarantee a named connector, custom integration or included professional-service hours." ] } ] }, { "path": "/case-studies/", "title": "Examples and incident analysis", "intro": "See how the controls would work in realistic situations, and read the external research behind two failure analyses. No customer deployment story is represented here.", "sections": [ { "id": "case-types", "kind": "definitions", "heading": "Three evidence types have different jobs.", "items": [ { "title": "Example workflow", "body": "An example task with a control path and intended result. It explains a decision, not a measured deployment outcome." }, { "title": "Incident analysis", "body": "An attributed public researcher report, followed by DriftGate's control-design interpretation. The event was not a DriftGate customer incident." }, { "title": "Customer case study", "body": "A real customer's work and verified results would need customer authorization and evidence. None is presented on this website." } ] }, { "id": "case-examples", "kind": "editorial", "heading": "Follow the decision all the way to the result.", "body": [ "The environment example separates a portable approved setup from personal credentials. The refund example binds approval to the actual amount, order and destination. The prompt-injection example treats retrieved material as data, not authority. The learning example keeps a proven fix separate from a private conversation.", "Each workflow labels its local simulation and points to connected capabilities. Its intended result remains a design goal until tested in a qualified system." ] }, { "id": "case-research", "kind": "evidence", "heading": "Public reports help frame the boundary.", "body": [ "The linked Invariant report describes a controlled demonstration involving untrusted issue content and access to a private repository. The linked Lasso report examines a shopping assistant moving away from its intended purpose. Read the original sources for their facts; the site uses them to explain why source content, task scope and action authority must stay distinct." ] } ], "exampleCollection": { "heading": "Four ways to inspect the model", "intro": "Example workflows ยท local simulations", "allLink": "Browse all 24 example workflows" }, "reportCollection": { "heading": "Incident analysis from public research", "intro": "Read the original report and our separate control-design interpretation. These are not customer results." } }, { "path": "/platform/drift/", "title": "Understand drift", "intro": "Drift is a difference between intended and observed state or behavior. The first question is what changed; the next is whether the change matters for this task and authority.", "sections": [ { "id": "drift-scope", "kind": "definitions", "heading": "Drift has more than one shape.", "items": [ { "title": "Configuration, tools and models", "body": "An active client may load a different profile, tool revision or supported model setting than the one approved for its project." }, { "title": "Identity, permission and policy", "body": "A grant can be revoked, a role changed or a policy revised while an approval or task is in progress." }, { "title": "Instructions, behavior and workflow", "body": "An agent may follow stale instructions, take a new path through tools or produce an outcome outside the intended task." }, { "title": "Cost, data and knowledge", "body": "Usage can exceed an expected bound, retrieval can reach a different source, or context can carry content into the wrong audience." }, { "title": "Outcomes", "body": "The observed pattern of errors, escalations, refunds or successful resolutions may change from the intended distribution, even when a single task appears plausible." } ] }, { "id": "drift-example", "kind": "editorial", "heading": "Compare intended state with what the runtime shows.", "body": [ "Suppose a team approves a project profile with a reviewed tool revision and a staging-only connection. A supported client starts with an older tool and a personal account. The saved profile shows intent; the observed client and connection show a mismatch. Resolve the exact artifact and account binding before claiming the project environment is restored.", "For a refund, permission or policy drift may change the allowed action after an earlier review. Re-evaluate material inputs and current scope at the qualified effect boundary. A lost provider response is a separate execution uncertainty: reconcile the original operation before retry." ] }, { "id": "drift-response", "kind": "sequence", "heading": "Make the response proportional.", "items": [ { "title": "Detect", "body": "Collect the intended revision and observed state with provenance; identify what is unknown." }, { "title": "Classify", "body": "Separate configuration repair from permission or policy changes, behavior review and uncertain effects." }, { "title": "Decide", "body": "Warn, require review or enforce only where the integration supports that control mode." }, { "title": "Verify", "body": "Read back the resulting state or reconcile the original effect, then retain the evidence and relevant revision." } ] }, { "id": "drift-limit", "kind": "evidence", "heading": "Detection is not universal visibility.", "body": [ "The platform can reason only over connected sources and qualified observations. An installed artifact is not proof that a client loaded it. An inventory does not discover every unconnected shadow agent. A post-action signal can support investigation without claiming it prevented the effect." ] } ] }, { "path": "/platform/availability/", "title": "Platform scope and availability", "intro": "This website explains the full platform direction. A page describing a control does not certify that it is released, connected or enforcing in your environment.", "sections": [ { "id": "availability-focus", "kind": "editorial", "heading": "Start with a personal environment, then qualify each expansion.", "body": [ "The near-term product focus is Solo: a project profile for a supported coding client such as Codex or Claude Code, with independently authorized accounts and an observed client state. Scoped GitHub and Notion connections are early integration candidates, each requiring its own permissions and target binding. These are launch focus and candidate paths, not a claim that a specific release is live today.", "The larger platform model adds governance for consequential business operations, shared administration and reviewed learning. ACP adapters, broad enterprise connectors, native hosted agents and cross-tenant learning are planned qualification areas rather than established launch coverage. Ask which exact path exists in the release being evaluated, and verify it in the target environment." ] }, { "id": "availability-claims", "kind": "definitions", "heading": "Use precise status language.", "items": [ { "title": "Described capability", "body": "A published product model or design intent. It does not establish an active implementation." }, { "title": "Qualified integration", "body": "A specific client or business-system path tested against a named release and supported operation." }, { "title": "Observed control", "body": "A runtime readback showing an actual decision, effect or record in the target environment." }, { "title": "Planned scope", "body": "A direction for later qualification. It is not a committed delivery date or a substitute for a scoped agreement." } ] }, { "id": "availability-next", "kind": "evidence", "heading": "Qualify the boundary before relying on it.", "body": [ "For Observe or Warn, inspect the source, coverage and delay of the signal. For Require Approval, check the material inputs and current authority bound to the decision. For Enforce, demonstrate a denied request at the real pre-effect path. For unknown outcomes, show how the original operation is reconciled before retry.", "Commercial, infrastructure and support scope belong in the relevant agreement. This site does not assert a named connector matrix, release date or live certification." ] } ] }, { "path": "/platform/learning/", "title": "Reviewed learning", "intro": "Learning is an accountable change process across operations, policy and security, not an automatic rewrite of an agent after every conversation.", "sections": [ { "id": "learning-improvements", "kind": "definitions", "heading": "Different lessons change different things.", "items": [ { "title": "Operational improvement", "body": "A better skill, instruction, project profile or workflow reduces repeated task friction without broadening authority by itself." }, { "title": "Policy improvement", "body": "A reviewed rule or approval path changes what is permitted and requires explicit policy ownership and release." }, { "title": "Security improvement", "body": "A tested guard, detection or isolation change addresses an observed exposure and needs independent validation of its control boundary." } ] }, { "id": "learning-loop", "kind": "sequence", "heading": "From recurring friction to a scoped release.", "items": [ { "title": "Observe", "body": "Capture the task, environment, evidence and recurring failure without treating raw conversation content as a reusable rule." }, { "title": "Retrieve or generate", "body": "Look for an existing approved pattern or prepare a candidate change tied to the problem." }, { "title": "Test independently", "body": "Check the candidate against the original failure and relevant adverse cases outside the proposing agent's self-assessment." }, { "title": "Approve", "body": "Review content, permissions, audience and owner before promotion." }, { "title": "Release or roll back", "body": "Publish a version to the approved scope, observe its effect and retain a way back." } ] }, { "id": "learning-sharing", "kind": "editorial", "heading": "The audience grows only with consent and review.", "body": [ "A private lesson can remain with its person or project. A team may propose it for an organizational catalog after review. Cross-tenant reuse is optional and requires its own consent and boundary; it is not implied by participation in a workspace.", "Permission to share a reviewed lesson is separate from permission to use data for model training. Neither follows automatically from observing a task." ] } ] }, { "path": "/architecture/", "title": "Architecture and authority", "intro": "Keep planner and runtime choices open while making the actor, authorized operation, effect and outcome explicit at the integration boundary.", "sections": [ { "id": "architecture-hierarchy", "kind": "definitions", "heading": "How an approved environment reaches a target.", "items": [ { "title": "Workspace", "body": "The ownership and collaboration boundary within an organization." }, { "title": "Project", "body": "A work context in the workspace that resolves an effective environment." }, { "title": "Profile", "body": "A versioned configuration selection for a supported client or workflow; it is not an authority boundary." }, { "title": "Target binding", "body": "An explicit association to the actual client, account, resource or execution target where the profile is consumed; authorization remains separate." } ], "body": [ "The broader tenancy model is Organization โ†’ Workspace โ†’ Application โ†’ Environment. Within a workspace, a project selects an effective environment for its work. A profile is a versioned configuration choice and a target binding connects that choice to a supported client, account or resource; neither is an additional tenant or a grant of authority.", "Copying a profile does not copy credentials or authorize a connection. Each connection needs its own account authorization and resource scope, and the actual target state must be observed before calling the environment ready." ] }, { "id": "architecture-contract", "kind": "editorial", "heading": "An entry point is not always the effect boundary.", "body": [ "MCP tool discovery or a qualified ACP session can help an agent reach the governance model. Neither alone proves that DriftGate can block an external write. Enforcement depends on the adapter or API path that owns the consequential operation before it happens.", "At that path, carry the exact actor, resource, operation, policy revision and material approval inputs. Retain an effect identity so an uncertain provider response can be reconciled without issuing a duplicate request. Design aims to keep the pre-effect decision low latency, but this website makes no measured latency claim." ] } ] }, { "path": "/solo/", "title": "Solo control", "intro": "A personal setup should travel across supported contexts while accounts and credentials remain independently authorized.", "sections": [ { "id": "solo-scope", "kind": "editorial", "heading": "One builder can still need a real operating model.", "body": [ "A workspace groups your projects. Each project can select a reviewed profile, and each supported client or target needs an explicit binding. This lets you identify which tools and instructions you intended to use and what the client actually loaded.", "Solo starts with private ownership and one builder/operator seat at $19 per month. Scoped authority, credential protection and safe recovery are foundational. Moving to a team adds shared ownership and administration rather than creating the first security boundary." ] } ] }, { "path": "/enterprise/", "title": "Enterprise control", "intro": "Departments can keep different runtimes and business systems while sharing clear ownership, authority, evidence and reviewed change.", "sections": [ { "id": "enterprise-ownership", "kind": "editorial", "heading": "Scale ownership before adding complexity.", "body": [ "Solo centers on one builder. Team introduces shared project baselines. Business extends administration and cross-team review. Enterprise scopes identity integration, policy ownership, evidence, lifecycle and deployment requirements through an agreement. All levels need the same distinction between a saved configuration, current permission and an observed effect.", "Organization-owned workloads should have their own identities and resource bindings. Employees should retain individual accountability. A shared profile does not authorize a shared login session, and removing one person's access should not remove an independent workload's legitimate authority." ] }, { "id": "enterprise-evaluation", "kind": "evidence", "heading": "Evaluate one consequential path end to end.", "body": [ "Choose a production change, customer account operation or financial export. Show who owns the workload, which resource it can reach, where current policy is checked, how approval is bound to the material request and what record proves the effect or uncertainty.", "Then test revocation, an out-of-policy request and a lost provider response. These checks reveal the difference between a catalog of intended controls and a qualified operating boundary." ] } ] }, { "path": "/solutions/engineering-teams/", "title": "Engineering teams", "intro": "Share the reviewed starting environment while each developer keeps individual account and resource authority.", "sections": [ { "id": "engineering-journey", "kind": "editorial", "heading": "From onboarding to verified change.", "body": [ "A project owner selects an approved profile of tools, skills and instructions. The new developer binds a supported client to that project and authorizes the required resources with their own account. The team verifies the loaded revision and observed connection state before declaring the environment ready.", "When a tool changes, review the exact difference and affected consumers. Release the new revision deliberately, preserve intentional overrides and retain a rollback path. A recurring setup repair can enter reviewed learning after an independent check." ] } ] }, { "path": "/solutions/customer-operations/", "title": "Customer operations", "intro": "Conversational help and consequential business action need different authority paths.", "sections": [ { "id": "customer-journey", "kind": "editorial", "heading": "Keep the conversation useful and the effect controlled.", "body": [ "A support, voice or sales agent may answer with relevant context. A refund, discount, subscription change or outbound message needs a defined operation, current scope and an effect boundary in the business system path.", "For a refund, evaluate the actor, order, amount and destination. An approval should bind to those inputs; if they change, review again. If the provider response is lost, reconcile the original operation before considering another request. The transcript alone does not establish whether money moved." ] } ] }, { "path": "/solutions/platform-security/", "title": "Platform and security leaders", "intro": "Know which connected workloads can act, who owns them and what evidence can support a decision or investigation.", "sections": [ { "id": "security-journey", "kind": "editorial", "heading": "Start with a sensitive operation, then test the boundary.", "body": [ "Map the workload identity, owner, connected resources and permitted operations. Ask whether the integration can only observe, can warn, can hold for approval or can enforce before the effect. Preserve the policy revision and decision alongside the resulting receipt.", "Test unauthorized input, revoked authority and an uncertain provider outcome in a qualified environment. A registered inventory improves connected-system visibility; it does not establish discovery of every unconnected shadow agent or prevention on every external path." ] } ] } ], "workflowGuides": [ { "number": 1, "heading": "Read the setup and the authorization separately.", "cues": [ { "title": "Evidence to inspect", "body": "Approved profile revision, observed client/tool revision, target binding and the independently authorized account or resource scope." }, { "title": "Control to apply", "body": "Repair the specific environment mismatch and verify the loaded state; never treat a copied profile as copied credentials." } ] }, { "number": 9, "heading": "Follow the refund from request to effect.", "cues": [ { "title": "Evidence to inspect", "body": "Requester, order, amount, destination, approval inputs, current policy and the provider's original effect identity." }, { "title": "Control to apply", "body": "Require approval when the material request needs it, re-evaluate changed inputs and reconcile an unknown outcome before retry." } ] }, { "number": 21, "heading": "Keep source content below instruction authority.", "cues": [ { "title": "Evidence to inspect", "body": "The retrieved document's provenance, the agent's original task, requested tool action and any attempted access to a protected resource." }, { "title": "Control to apply", "body": "Treat document instructions as untrusted data and deny an out-of-scope action at the qualified operation boundary." } ] }, { "number": 24, "heading": "Promote the fix, not the conversation.", "cues": [ { "title": "Evidence to inspect", "body": "Recurring failure, candidate revision, independent test result, reviewer, audience and rollback reference." }, { "title": "Control to apply", "body": "Release a tested lesson only to its approved scope; keep private context and model-training consent separate." } ] } ], "controlLoop": { "heading": "Gate. Drift. Learn.", "intro": "Choose a stage to see the decision and the evidence it should leave.", "steps": [ { "name": "Gate", "title": "Decide with current authority", "body": "Actor, resource and exact operation are checked before a qualified effect. Evidence: the policy decision and bound approval." }, { "name": "Drift", "title": "Compare intent with observation", "body": "The approved profile and current runtime state are compared. Evidence: revisions, target binding and a specific mismatch." }, { "name": "Learn", "title": "Review the better path", "body": "A candidate fix is tested independently, approved and released to a defined audience. Evidence: test result, reviewer and rollback revision." } ] } }