Vendor access
This part is for Aigna staff
Vendors see their own installation and the device reference they need to build it: device types, setup guides and models. Everything else stays with Aigna.
Go to your installationEngagement · Maintenance vendorAG-SVC-2026-01Simulated
Aigna and Keystone Service
In force · 10 sites shared · 3 jobs openchecked just now
- 10Sites in scope
- 3Jobs open
- 0Past target
- 825Days left
The scope
Sites
- Dublin office
- London office
- Copenhagen office
- New York office
- Chicago office
- Toronto office
- Juneau office
- Singapore office
- Tokyo office
- Melbourne office
What flows
- Offices and spaces in scope
- Jobs handed to the provider
- Visit readiness
Keystone Service sees a record of Aigna's only when it sits inside this scope, and work only when it was handed to Keystone Service. Aigna sets the scope; ask your contact to change it.
Activity
signed, and held in both audit logs- Aigna · Handed INC0041215 to Keystone Service: codec stuck after a power cutSigned by Aigna · in both audit logs
- Keystone Service · Booked an engineer for tomorrow morning on INC0041214Signed by Keystone Service · in both audit logs
- Aigna · Engagement signed by both sides, with the data processing agreementSigned by Aigna · in both audit logs
Standards
Aigna's standards apply to everything you do for Aigna. You can offer Keystone Service's own as a template: Aigna decides whether to adopt any of it.
How the two Keias connect
Keystone Service runs Keia in database mode: it shares and receives over the API and events, each one signed.
Aigna runs Keia in repo mode: what it shares leaves as a signed export, and what Keystone Service sends back arrives as a pull request a person reviews.
No shared database: each side keeps its own Keia and its own copy.
A provider's own Keia
This is Keystone Service's side of the engagement
Only Keystone Service's people see their own Keia. Aigna holds the same engagement under Vendors.
See Aigna's side