← All use cases 03 · BUSINESS OPERATIONS · PROPOSED WORKFLOW

Request an outcome. Keep the rules in the system.

Expose the same trusted business operation through forms, voice and authorised assistants.

Who this is for: Enterprise teams, business application owners and software architects. Illustrative concept, not a deployed OSYNIA capability.

01 · START WITH THE PROBLEM

What problem are we trying to solve?

Employees and agents need to learn application-specific screens to complete routine leave requests.

Relevant contracts: OSYNIA-C capability contract with input/output schema, preconditions, effects and approval policy.

EXAMPLE USER REQUEST

“Request annual leave for next Thursday and Friday.”

BEFORE · COMMON APPROACH

The employee locates the correct application and navigates several screens.
A voice assistant or agent must imitate the user interface and may break when layouts change.
Each channel may reimplement validation and business rules.

WITH OSYNIA · PROPOSED

The HR system publishes a typed leave-request operation with required fields and policies.
A form, voice client or authorised agent can collect the same validated inputs.
The backend checks identity, leave balance, policy and approvals.
The employee receives a real request reference, or a clear explanation of why it cannot proceed.

02 · STEP-BY-STEP USER JOURNEY

From request to a verifiable outcome.

Switch between General and Technical in the header to explore the same journey at two levels.

Describe the request

An employee tells the system which days they want off.

Map the natural-language request to a typed capability and collect unambiguous dates, employee identity and leave type.

Illustrative output

Proposed annual leave request with two dates

Discover the operation

The system finds the approved leave-request process.

Resolve capability ID hr.leave.request with input schema and policy requirements.

Illustrative output

Supported operation: request leave

Validate and authorise

The employer’s system checks available leave and who is allowed to submit.

Perform authentication, authorisation, precondition evaluation and server-side policy validation.

Illustrative output

Balance and approval rules checked

Confirm before action

The employee reviews the dates and confirms the submission.

Require user confirmation for the state-changing operation and use an idempotency key.

Illustrative output

Confirmation received

Submit and report

The system creates the request and returns its status, such as awaiting approval.

Execute the capability, log the transaction, return typed status and correlation ID.

Illustrative output

Example status: request submitted, pending manager approval

03 · RESPONSE & OUTCOME

What would the person see?

ILLUSTRATIVE SYSTEM RESPONSE

“Your two-day annual leave request is ready. Review the dates and confirm submission.”

ILLUSTRATIVE COMPLETION

Example completion: Leave request LR-1042 submitted and awaiting manager approval — not automatically approved.

A proposed success message must be backed by actual execution and verification in a real implementation.

04 · UNDER THE HOOD

How the proposed technology fits together.

This example depends on information that explains what it is, trusted links to other information, and clearly described operations when an action is needed.

What must be in place:

Authenticated employee identity and relevant permissions are essential.
Dates, timezone and employee policies must be validated by the HR backend.
An approval workflow is not equivalent to automatically granting leave.

Resources: Capability registry entry, employee policy reference and request status
Contracts: OSYNIA-C capability contract with input/output schema, preconditions, effects and approval policy

Proposed system sequence

Interpret request
Capability discovery
Validate parameters
Authorise and confirm
Execute
Return audited outcome

Security and governance controls

OIDC identity
Policy enforcement
Confirmation boundary
Idempotency
Audit

Illustrative JSON contract

{
  "capability": "hr.leave.request",
  "input": {
    "leaveType": "annual",
    "days": 2
  },
  "preconditions": [
    "activeEmployment",
    "sufficientBalance"
  ],
  "requiresConfirmation": true,
  "result": {
    "status": "pending_approval"
  }
}

RELEVANT OSYNIA SPECIFICATIONS

Capabilities & IntentTrust & GovernanceExperience & Accessibility

Explore proposed specifications →

05 · REAL-WORLD VALIDATION

How would we know it works?

These are proposed measures, not published results.

Task completion

Successfully submitted valid requests / attempted valid tasks

Operational safety

Unauthorised or unintended state changes detected

Channel consistency

Same operation outcome across form, voice and agent clients

Requirements for adoption

Authenticated employee identity and relevant permissions are essential.
Dates, timezone and employee policies must be validated by the HR backend.
An approval workflow is not equivalent to automatically granting leave.

Limits and trade-offs

Complex policy interpretation may still require human review.
The standard does not replace HR systems or their business rules.
Generated user interfaces still need accessibility and security testing.

This page presents research hypotheses, not verified performance improvements, customer results or a live demonstration.