Product architecture

Can I accept this?

GuardianChain's architecture connects human authority, bounded scope, machine action and outcome evidence. It complements identity, orchestration, policy and logging rather than replacing them. This design-partner site provides product information and inquiries, not platform access.

Two engineers testing a white robot in an engineering workshop
Illustrative photograph, not a GuardianChain deployment.Photo: ThisIsEngineering / Pexels
The recipient's question

Five questions before acceptance.

Someone is handing you work that machines helped produce. Before you sign off, you need to inspect a bounded handoff, not a confident summary. GuardianChain's architecture centers on that moment.

  1. Who authorized the workA named, accountable person or role, not a prompt or an API key.
  2. Within what limitsPermitted actions, resources, conditions and expiry.
  3. What was actually done or observedThe consequential actions, linked to the grant they relied on.
  4. Which evidence supports itReferences the recipient can inspect separately from the producer's summary.
  5. What is still unresolvedGaps, contradictions and missing approvals, stated rather than hidden.
The handoff

Authority, scope, action, evidence. Then the recipient decides.

AUTHORITY → SCOPE → ACTION → EVIDENCE → RECIPIENT DECISIONArchitecture overview
  1. Who allowed this?AuthorityRecorded by producer

    A named person or role grants the work.

    Record contents: the accountable grantor and the grant itself. A credential proves access, not permission for this specific work.

  2. Within what limits?ScopeRecorded by producer

    What may be done, on which resources, until when.

    Record contents: permitted actions, resources, conditions and expiry. Refusals and restraint are part of the record too.

  3. What was done or observed?ActionLinked to grant

    Consequential machine actions, tied to the grant they relied on.

    Record contents: distinguish the producer's claims from recorded observations, including where work stopped or stepped outside its scope. If target readback is unavailable, the outcome stays unresolved rather than being treated as confirmed.

  4. Can I check it myself?EvidenceInspectable by recipient

    References a recipient can inspect independently.

    Record contents: evidence references plus a list of what remains unresolved. Integrity checks can show the record is intact and consistent; they do not show it is complete.

  5. Can I accept this?Recipient decisionHuman judgement, not a check result

    The recipient accepts, holds and requests evidence, or challenges.

    This step is never produced by verification. The recipient weighs completeness, business fitness and legal or contractual obligations, then decides.

Open any step for detail. The fifth step is set apart because it belongs to the recipient, not to the record.

GuardianChain architecture shown for explanatory purposes. Three U.S. provisional patent applications have been filed covering the underlying technology.
Verification is not acceptance.

Technical verification asks whether a record is intact and consistent. Integrity and consistency do not prove the work is complete, fit for your business purpose, or legally compliant. The recipient decides whether the work is acceptable for their purpose. GuardianChain is designed to support the first and leaves the second with the recipient.

Verification can indicate
  • The record is intact and has not been altered
  • Its parts are internally consistent
  • Evidence references resolve to what they name
Verification does not establish
  • That the work is complete
  • That it is fit for your business purpose
  • That it meets legal, regulatory or contractual obligations
The recipient may
  • Accept the handoff
  • Hold and request more evidence
  • Challenge what is claimed
GuardianChain architecture shown for explanatory purposes. Three U.S. provisional patent applications have been filed covering the underlying technology.

Without the record, and with the evidence handoff

An example of a fragmented handoff. Existing tools may already provide parts of these controls; the distinction is what travels to the recipient for inspection.

LinkWithout the recordWith the evidence handoff
AuthorityAn approval held in a separate ticket or identity systemThe relevant named grant and its source travel with the handoff
ScopeLimits and expiry reconstructed from several toolsStated limits and an expiry the recipient can read
ActionLogs inside each system showing what ranConsequential actions linked to the grant they relied on
EvidenceSummaries, screenshots and manual reconstructionReferences the recipient can inspect independently
UnresolvedMissing pieces emerge while the recipient reconstructs the handoffOpen issues listed before the recipient decides
GuardianChain architecture shown for explanatory purposes. Three U.S. provisional patent applications have been filed covering the underlying technology.
Why now

AI can act faster than organizations can review what happened.

The bottleneck is moving from generating work toward accountable acceptance of it. This is the problem we are investigating with design partners, not a measured product result.

  1. Agent autonomy is expandingAgents increasingly take multi-step actions with less step-by-step human direction.
  2. Tool use crosses systemsOne task can touch repositories, tickets, payments and vendor services.
  3. Responsibility crosses boundariesWork produced by one team or organization is accepted by another.
  4. Evidence is fragmentedLogs, approvals, tickets, vendor records and model reports sit in different places.
Public context, cited for orientation only
  • NIST's AI Agent Standards Initiative (February 2026) focuses on agents capable of autonomous action and on secure, interoperable ecosystems. NIST CAISI initiative
  • A January 2026 NIST request for information states that security challenges hinder agent adoption today. It is a research effort, not an adopted standard. NIST RFI announcement
  • NIST is developing an AI RMF profile for trustworthy AI in critical infrastructure (April 2026 concept note); it does not certify products. NIST concept note
  • EU general-purpose AI obligations include technical documentation; additional risk, incident and cybersecurity duties apply to systemic-risk model providers, not every AI application. Duties began 2 August 2025, Commission enforcement powers 2 August 2026, with transition to 2 August 2027 for earlier models, subject to applicability and exceptions. EU GPAI obligations EU GPAI guidelines

GuardianChain does not claim to meet any regulation or certification, and no record prevents every failure. See Research and sources.

Product inventory

What each part does, and what exists today.

Available today: this informational website, design-partner and contact inquiries, and Partner Access to the inquiries you submitted while signed in. This website does not provide platform access.
  1. Governed authority and evidence substrateGC-1Holds grants, scopes, linked actions and evidence references.
  2. Governed connector and session interfaceGuardianBridgeWhere sessions are opened, bounded and closed against GC-1.
  3. Portable evidence projectionFactReceiptWhat the recipient carries away and inspects independently.

Arrows show the architectural roles of GC-1, GuardianBridge and FactReceipt. This website does not connect to their runtimes.

GuardianChain architecture shown for explanatory purposes. Three U.S. provisional patent applications have been filed covering the underlying technology.
Canonical authority and evidence substrate

GC-1

Design-partner stage

The record of who authorized what, within which scope, and what evidence exists for the outcome. The other parts depend on it.

Who it is for
Platform, security and risk teams that need one authoritative record of delegated machine actions across vendors.
The problem
Authority, scope, decisions and evidence live in separate systems with separate logs, so nobody can reconstruct the full chain after the fact.
The workflow
A human grant establishes scope. Actions taken under it are linked back to that grant. Evidence attaches to the outcome. Revocation and expiry are recorded rather than inferred.
Evidence or output
A canonical, append-oriented record of grants, scopes, decisions and evidence references that FactReceipts can be issued from.
Availability and site access
This website explains GC-1 and does not provide GC-1 platform access. Availability is discussed and qualified separately with design partners.
Your next step
Bring one real delegation workflow to a design-partner conversation so we can test the record model against it.
Human and machine interface for governed sessions

GuardianBridge

Design-partner stage

Where a person grants, bounds, watches and ends a machine session, so authority is explicit at the moment it matters.

Who it is for
Operators and approvers who hand work to agents and must stay accountable for it.
The problem
Agent sessions start from prompts and credentials. The human decision that should bound them is rarely explicit or recorded.
The workflow
Open a governed session, state the scope, let the agent work inside it, review consequential steps, then close or requalify. Authority does not silently renew.
Evidence or output
Session-level records of grant, scope, review and closure, written to GC-1.
Availability and site access
This website explains GuardianBridge; it does not open governed sessions. Demonstrations do not establish general availability.
Your next step
Tell us where your approvers lose track of what an agent was allowed to do.
Portable, independently verifiable evidence

FactReceipt

Design-partner stage

A statement a recipient can check without trusting the producer: what was claimed, by whom, under what authority, with what support.

Who it is for
Recipients of machine-assisted work: clients, auditors, counterparties and incident teams.
The problem
Recipients are asked to accept work on the producer's word, using logs held by the system that did the work.
The workflow
Issued from the GC-1 record, travels with the work, and is inspected separately. Integrity, issuer and evidence coverage are distinct checks, not one universal pass.
Evidence or output
A portable receipt plus supporting material for independent technical inspection. Acceptance remains the recipient's business decision.
Availability and site access
No receipts are issued by this website; availability beyond this site requires separate qualification.
Your next step
Share what a recipient on your side would need to see before accepting machine-assisted work.
Positioning

An evidence handoff layer among the systems you already run.

Authorization, logging and observability serve real purposes. By themselves, they do not establish that another recipient can accept the work for their purpose.

Your existing systems, unchanged
  • Identity
  • Orchestration
  • Policy
  • Logging and observability
  • Business systems

Each serves a real purpose. None, by itself, establishes that another recipient can accept the work.

Evidence handoff layerAn evidence handoff between producer and recipientDraws on what those systems already record, and packages authority, scope, action, evidence and open issues for the recipient.
Where we fit
  • Consequential handoffs that cross a team or organization
  • Recipients who must decide, not just observe
  • Work where evidence is scattered across tools and vendors
Where we do not fit
  • Replacing identity, policy, orchestration or logging
  • Sitting in every request path as a gateway
  • Certifying compliance or deciding on the recipient's behalf
  • Low-stakes work nobody needs to accept formally
GuardianChain architecture shown for explanatory purposes. Three U.S. provisional patent applications have been filed covering the underlying technology.
Typical coverage by category, in isolation. Individual products vary; this is our framing, not a benchmark.
CategoryPrimary jobWho authorizedPermitted scopeDecision linkedIndependently checkable
Identity providersAuthenticate people, services and agentsPartlyNot by itselfNot by itselfNot by itself
Agent orchestrationPlan and run multi-step agent workNot by itselfPartlyYesNot by itself
Tool connectivityConnect agents to tools and dataNot by itselfPartlyYesNot by itself
Policy enginesEvaluate rules at decision timeNot by itselfYesPartlyNot by itself
Logs and observabilityRecord events inside each systemNot by itselfNot by itselfPartlyPartly
GuardianChain architectureConnect the four, alongside the systems aboveArchitectural focusArchitectural focusArchitectural focusArchitectural focus

Bring one consequential handoff.

Choose one piece of AI or machine-assisted work where the recipient currently trusts summaries, screenshots, scattered logs or manual reconstruction. We will map it end to end and tell you honestly where GuardianChain does and does not fit.

Our technology ecosystem

Built with established tools.

The tools behind this website, alongside selected names from the wider GuardianChain stack. Directory listings are not live platform integrations, partnerships or endorsements.

  • 04 entriesWebsite tooling
  • 01 entriesConnector attached
  • 28 entriesStack directory
  • ReplitDevelopment & sign-inWebsite tooling
  • ReactWebsite interfaceWebsite tooling
  • StorybookComponent documentationWebsite tooling
  • PostgreSQLMarketing data & sessionsWebsite tooling
  • RailwayApplication hostingStack directory
  • NeonManaged PostgreSQLStack directory
  • AWSCloud infrastructureStack directory
  • CloudflareEdge & storageStack directory
  • BackblazeArchive storageStack directory
  • CloudinaryMedia deliveryStack directory
  • AnthropicAI modelsStack directory
  • OpenAIAI modelsStack directory
  • OpenRouterModel routingStack directory
  • DeepSeekAI modelsStack directory
  • Together AIModel hostingStack directory
  • Hugging FaceOpen-source AIStack directory
  • Mistral AIAI modelsStack directory
  • Stability AIGenerative modelsStack directory
  • xAIAI modelsStack directory
  • CohereAI & embeddingsStack directory
  • WorkOSIdentity & SSOStack directory
  • GitHubSource collaborationStack directory
  • GitHub ActionsBuild automationStack directory
  • npmPackage registryStack directory
  • PostHogProduct analyticsStack directory
  • SentryError monitoringStack directory
  • SlackTeam communicationStack directory
  • UpstashCachingStack directory
  • AlchemyBlockchain infrastructureStack directory
  • PolygonBlockchain networkStack directory
  • OptimismBlockchain networkStack directory
  • StripePayment infrastructureStack directory
  • ResendEmail connectorConnector attached
Inspect all 33 entries by status

Website tooling (4)

Tools used to build and operate this informational site.

Connector attached (1)

Attached to the workspace. Email sending is not implemented.

Stack directory (28)

Referenced in the GuardianChain technology directory. Not a live integration on this site.

Names and marks belong to their respective owners, shown unmodified for identification. No affiliation or endorsement is implied.