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.

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.
- Who authorized the workA named, accountable person or role, not a prompt or an API key.
- Within what limitsPermitted actions, resources, conditions and expiry.
- What was actually done or observedThe consequential actions, linked to the grant they relied on.
- Which evidence supports itReferences the recipient can inspect separately from the producer's summary.
- What is still unresolvedGaps, contradictions and missing approvals, stated rather than hidden.
Authority, scope, action, evidence. Then the recipient decides.
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.
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.
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.
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.
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.
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.
- The record is intact and has not been altered
- Its parts are internally consistent
- Evidence references resolve to what they name
- That the work is complete
- That it is fit for your business purpose
- That it meets legal, regulatory or contractual obligations
- Accept the handoff
- Hold and request more evidence
- Challenge what is claimed
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.
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.
- Agent autonomy is expandingAgents increasingly take multi-step actions with less step-by-step human direction.
- Tool use crosses systemsOne task can touch repositories, tickets, payments and vendor services.
- Responsibility crosses boundariesWork produced by one team or organization is accepted by another.
- Evidence is fragmentedLogs, approvals, tickets, vendor records and model reports sit in different places.
- 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.
What each part does, and what exists today.
- Governed authority and evidence substrateGC-1Holds grants, scopes, linked actions and evidence references.
- Governed connector and session interfaceGuardianBridgeWhere sessions are opened, bounded and closed against GC-1.
- 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.
GC-1
Design-partner stageThe 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.
GuardianBridge
Design-partner stageWhere 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.
FactReceipt
Design-partner stageA 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.
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.
- Identity
- Orchestration
- Policy
- Logging and observability
- Business systems
Each serves a real purpose. None, by itself, establishes that another recipient can accept the work.
- Consequential handoffs that cross a team or organization
- Recipients who must decide, not just observe
- Work where evidence is scattered across tools and vendors
- 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
| Category | Primary job | Who authorized | Permitted scope | Decision linked | Independently checkable |
|---|---|---|---|---|---|
| Identity providers | Authenticate people, services and agents | Partly | Not by itself | Not by itself | Not by itself |
| Agent orchestration | Plan and run multi-step agent work | Not by itself | Partly | Yes | Not by itself |
| Tool connectivity | Connect agents to tools and data | Not by itself | Partly | Yes | Not by itself |
| Policy engines | Evaluate rules at decision time | Not by itself | Yes | Partly | Not by itself |
| Logs and observability | Record events inside each system | Not by itself | Not by itself | Partly | Partly |
| GuardianChain architecture | Connect the four, alongside the systems above | Architectural focus | Architectural focus | Architectural focus | Architectural 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.
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.
Inspect all 33 entries by status
Website tooling (4)
Tools used to build and operate this informational site.
- ReplitDevelopment & sign-in
- ReactWebsite interface
- StorybookComponent documentation
- PostgreSQLMarketing data & sessions
Connector attached (1)
Attached to the workspace. Email sending is not implemented.
- ResendEmail connector
Stack directory (28)
Referenced in the GuardianChain technology directory. Not a live integration on this site.
- RailwayApplication hosting
- NeonManaged PostgreSQL
- AWSCloud infrastructure
- CloudflareEdge & storage
- BackblazeArchive storage
- CloudinaryMedia delivery
- AnthropicAI models
- OpenAIAI models
- OpenRouterModel routing
- DeepSeekAI models
- Together AIModel hosting
- Hugging FaceOpen-source AI
- Mistral AIAI models
- Stability AIGenerative models
- xAIAI models
- CohereAI & embeddings
- WorkOSIdentity & SSO
- GitHubSource collaboration
- GitHub ActionsBuild automation
- npmPackage registry
- PostHogProduct analytics
- SentryError monitoring
- SlackTeam communication
- UpstashCaching
- AlchemyBlockchain infrastructure
- PolygonBlockchain network
- OptimismBlockchain network
- StripePayment infrastructure
Names and marks belong to their respective owners, shown unmodified for identification. No affiliation or endorsement is implied.
GuardianChain
