Automate credibility

Use Access Policies (APs) to gate participation, automate workflows, and manage risk dynamically.

APs read DISC Scores and Metric Health Factors in real time to determine eligibility for actions such as onboarding, trading, or reward access.

Note: Access Policies (APs) serve as enforcement logic for trust data. They interpret real-time DISC and Metric Health values, issuing short-lived eligibility tokens that applications can verify before permitting actions.

---

Create an Access Policy (AP)

POST /v1/policies/ap
{
  "policy_id": "AP_LEND_V1",
  "rules": {
    "disc_min": 60,
    "metrics": {"finance": 0.70, "compliance": 0.75},
    "verification": ["zk-KYC (ID + AML)"]
  },
  "ttl_seconds": 600
}

---

Check Access

POST /v1/policies/ap/check
{
  "policy_id": "AP_LEND_V1",
  "subject_tris": "tris:0xUSER..."
}

Response

{
  "granted": true,
  "eligibility_token": "tok_0x...",
  "expires_at": "2025-11-03T09:42:00Z"
}

---

Example Use Case

• A DeFi app uses an AP to allow lending access only to users with a DISC Score above 70 and a Compliance metric above 0.8.

• A VP tracks repayment consistency and updates DISC accordingly after each verified action.

Together, these create programmable trust cycles — enforceable, measurable, and transparent.

Tip: Access Policies can be chained together for multi-stage workflows. For example, a user may first pass an onboarding AP (DISC ≥ 55), then a trading AP (Finance ≥ 0.75), and finally a reward-claim AP (Compliance ≥ 0.8). This layered gating provides granular control without redundant checks.

---

FAQs

What is an Access Policy (AP)? An AP defines eligibility and verification requirements for participation in an app, protocol, or system. It references DISC Scores and Metric Health Factors in real time to make eligibility decisions.

How do VPs and APs work together? Validation Policies handle how credibility is scored, while Access Policies handle how that credibility is used. The typical flow is: evaluate VP → update DISC → verify AP → grant or restrict access.

Can I gate access by a single metric instead of a full DISC Score? Yes. Access Policies can specify per-metric thresholds — for example, requiring Finance ≥ 0.75 or Compliance ≥ 0.8.

Can I create multiple Access Policies to safeguard more than one system? Yes. Developers and organizations can deploy multiple Access Policies (APs) across different systems, environments, or product modules. Each AP can define unique eligibility parameters, DISC or metric thresholds, and verification requirements. This allows you to segment access logic — for example, separate APs for user onboarding, governance participation, or borrowing eligibility — while maintaining unified enforcement under your organization’s TRIS ID.

Are AP checks cached? Each access check issues a short-lived eligibility token (default 10 minutes). Once the token expires, revalidation is required to maintain integrity.

Can APs work for off-chain systems? Yes. Eligibility tokens generated through APs can authorize both on-chain and off-chain workflows, such as gated API calls, internal dashboards, or credit-based reward systems.

Do APs support complex conditions? Yes. Access Policies support composite AND/OR logic, nested thresholds, and optional verification conditions such as identity statuses (zk-KYH, zk-KYC [ID only], zk-KYC [ID + AML], or BAD Status validation).

---