Product Concept

The product is Actagate. Its development codename was ringi (Japanese: 稟議, the corporate approval ritual). Written for international partners, investors, and English-speaking design partners.

Requests, approvals, and manual execution work through Web and email. Slack is an optional integration for notifications and Slack-specific stamp and declaration flows.

One line

From request to approval to execution. One flow, no guesswork, powered by AI.

Every “can I?” in the company, on one decision layer.

The problem

Approvals happen everywhere and finish nowhere.

Fragmented. A manager approves things in a workflow tool, in five SaaS apps’ built-in approvals, in Slack DMs, and out loud. In Japan, ~68% of companies run multiple workflow tools in parallel; 95% say they want one.
Approval is where the tools stop. After “approved”, a human in IT still creates the account, grants the permission, raises the card limit. That work is invisible, slow, and error-prone.
Nothing tracks what the approval produced. Seats, permissions, credentials, budgets: the artifacts of approval live in a spreadsheet that is always out of date and never revoked.
Lightweight approvals leave no record. A thumbs-up in chat is an approval in practice and nothing in an audit.

The insight

Approval is not a form. It is a decision about a change. If you model the change explicitly, you can:

show approvers what will actually happen (and cost) instead of a document,
execute the change automatically the moment it is approved,
record what the change produced and when it should be undone,
and measure decision flow as a by-product, because every decision passes through one layer.

This is the terraform plan idea applied to corporate approvals.

The product: a five-stage pipeline

⓪ Intake       Catalog first. Structured request forms for the routine 90%; an AI
                 assistant only when you don't know which form. Multiple catalog items
                 can be bundled into one request and the approval routes merge automatically.

① Plan approval Approvers see the execution plan: the concrete changes + cost + expiry.
                 Approve on the Web or through the optional Slack integration.
                 The approved plan is hashed; execution must match that plan.

② Execution     If there's an API, it runs (Google Workspace, AWS IAM Identity Center).
                 If not, a runbook task with evidence capture goes to a human.
                 Both paths produce the same ledger record.

③ Grants ledger Every artifact of an approval, with owner / justifying approval / cost /
                 expiry. Expiring grants warn, then auto-revoke or fall back to a runbook.

④ Observability Lead time, backlog, execution success, live grants. Measured, not surveyed.

Bundled requests and shared approvers

An engineer needs an AWS IAM identity and read access to an S3 bucket. Traditionally that is two requests and the manager stamps twice.

Before:  IAM   → manager → AWS admin  → create
         S3    → manager → data owner → grant

After:   IAM + S3 (one request)
         → manager (once)
         → AWS admin ∥ data owner (in parallel)
         → both changes execute, both grants land in the ledger

Route merging is deterministic: shared approvers are deduplicated at their earliest step, independent approvers run in parallel.

Approval has a gradient

Not every decision deserves a workflow. The product meets each level where it lives.

Level	Shape	Record
L0 Stamp	One emoji reaction on any Slack message	Who / when / what / permalink, append-only. Can be promoted to L2 later
L1 Declare	“I’m doing X.” Manager can veto within 24h; silence is consent	Declaration, expiry, veto reason
L2 Formal	Catalog form → multi-step route → execution	Full plan, per-step hash, execution, grant
L3 Critical	Strict evidence, reserved for board-level (roadmap)	Planned

Why this wins

Category	Examples	What they do	Where they stop
Workflow / approval tools	Kissflow, Pipefy, Bakuraku (JP), kickflow (JP)	Route a form to approvers	At “approved”. Execution is manual
iPaaS / automation	Workato, Zapier, Yoom (JP)	Execute after a trigger	Execution without an approval plan or revocation ledger
SaaS management	Zluri, Torii, Josys (JP)	Discover and offboard SaaS seats	Event-driven (join/leave). Don’t know why a grant exists
Employee service desk	ServiceNow, Moveworks	Same idea at enterprise scale	Enterprise pricing, months of implementation

Actagate targets companies of 30-300 people that need approval, execution, and a grants ledger without a dedicated ServiceNow team. Catalogs can be edited through the builder, with optional AI drafting.

Inspirations, deliberately: Databricks One (a single front door), ServiceNow (catalog + fulfillment), Moveworks (conversational intake as a fallback, not the main path), Datadog (observability as a by-product), Terraform (plan before apply).

Architectural principles

These are enforced in code and tests, not just in slides.

Plan-hash invariant. Every approval step records the hash of the plan it approved. Execution (grant and revoke) refuses to run unless all step hashes match the current plan. AI has no path to alter an approved plan.
Append-only audit. The audit table has insert-only access from the application. No update or delete code path exists.
No resident jobs. Expiry, veto windows, and revocation are evaluated lazily on event and read paths with idempotent claims. There is no cron to fail silently.
Organization scope: business data access is bound to an organization ID, with tests that reject access across organizations. Separate databases and encryption keys per tenant are an accepted design that has not been implemented.
Runbook fallback: supported executor failures move to human tasks with evidence capture. A failed plan-hash check blocks automatic execution.

LLM assistance is optional. Intake falls back to keyword suggestions; AI catalog drafting becomes unavailable when its provider fails. The product is named Actagate, and display names remain configurable. Japanese and English UI strings are externalized.

Day-one use case: just-in-time AWS access

The request, approval, execution, and revocation paths are implemented. A configured AWS connection is needed to verify them in a deployment.

Engineer requests a permission set on an AWS account with an expiry date (catalog form, 30 seconds)
Manager and AWS admin approve the plan on the Web or in Slack (they see account, permission set, expiry)
AWS IAM Identity Center assignment is created automatically
The grant appears in the ledger with owner, justification, and expiry
Three days before expiry, owner and issuer are warned
At the next event or page read after expiry, the assignment is deleted with the same hash check as the grant. If AWS is unreachable, a revocation runbook goes to the admin

From there the same machinery covers Google accounts, SaaS seats, shared-drive permissions, corporate card limits, and expense pre-approvals.

Implementation status (October 2026)

Implemented: Web and email flows, optional Slack, L0 / L1 / L2, bundles with route merging, executors and manual runbooks, grants ledger with expiry and revocation, dashboard and CSV audit export, AI intake with keyword fallback, Japanese and English UI, product help
Catalog builder, AI drafting, template gallery, roles, attachments, comments, cloud runbooks, OIDC login, and generic SAML 2.0 login are implemented. SSO enforcement settings, user consolidation, and tenant provisioning remain planned
Deployment support: single-tenant Docker Compose and AWS ECS workflows. Production deployment and restoration results require separate operational records
Planned: tenant databases and keys, billing, and an operator console

What we are looking for

Design partners (30-300 people, Google Workspace or AWS, with or without Slack) willing to run one approval flow
Feedback on the wedge: is JIT access the right first door, or is SaaS seat management more urgent in your market?