Coding Assistant — PlantoOS Product

The context problem in developer workflows

●AI coding assistants lose context between sessions — developers re-explain patterns, conventions, and architectural decisions every time.
●Suggested code has no traceability — when a suggestion causes a bug, there's no lineage to the context that produced it.
●Code actions are ungoverned — assistants can read, modify, and suggest across the entire codebase without scope boundaries.
●Team knowledge stays siloed — individual developer context never aggregates into organizational coding knowledge.

What Coding Assistant provides

Coding Assistant›Editor›fraud-detection.ts

Context Active

Explorer

src

services

fraud-detection.ts

risk-scoring.ts

transaction-validator.ts

models

utils

config

tests

package.json

tsconfig.json

fraud-detection.ts×

risk-scoring.ts

1import { TransactionEvent } from '../models/transaction';

2import { RiskScore, FraudSignal } from '../models/risk';

3import { PolicyEngine } from '../core/policy-engine';

4

5export class FraudDetectionService {

6 private policyEngine: PolicyEngine;

7 private confidenceThreshold = 0.85;

8

9 async detectFraud(event: TransactionEvent): Promise<FraudSignal> {

10 const riskScore = await this.calculateRiskScore(event);

11 const behavioralSignals = await this.analyzeBehavior(event);

12

13 // Combine risk factors with behavioral analysis

14 const combinedScore = this.fuseSignals(riskScore, behavioralSignals);

15

16 if (combinedScore.confidence > this.confidenceThreshold) {

17 await this.policyEngine.evaluate('fraud-alert', combinedScore);

18 return { flagged: true, score: combinedScore, action: 'review' };

19 }

20

21 return { flagged: false, score: combinedScore, action: 'pass' };

22 }

23}

Context Memory

Related Files

risk-scoring.ts

transaction-validator.ts

policy-engine.ts

Architecture Notes

Fraud detection uses a two-stage pipeline

Risk scoring feeds into behavioral analysis

Policy engine gates all alert dispatches

Past Decisions

Switched from threshold-only to combined scoring (v2.3)

Added behavioral signals in sprint 47

Confidence threshold raised from 0.75 to 0.85

PR Feedback

"Consider adding rate limiting" — @sarah

"Good separation of concerns" — @alex

"Add integration test for edge cases" — @mike

Persistent repo context

The assistant remembers repository context across sessions.

Coding Assistant›Editor›fraud-detection.ts

Context Active

Explorer

src

services

fraud-detection.ts

risk-scoring.ts

transaction-validator.ts

models

utils

config

tests

package.json

tsconfig.json

fraud-detection.ts×

risk-scoring.ts

1import { TransactionEvent } from '../models/transaction';

2import { RiskScore, FraudSignal } from '../models/risk';

3import { PolicyEngine } from '../core/policy-engine';

4

5export class FraudDetectionService {

6 private policyEngine: PolicyEngine;

7 private confidenceThreshold = 0.85;

8

9 async detectFraud(event: TransactionEvent): Promise<FraudSignal> {

10 const riskScore = await this.calculateRiskScore(event);

11 const behavioralSignals = await this.analyzeBehavior(event);

12

13 // Combine risk factors with behavioral analysis

14 const combinedScore = this.fuseSignals(riskScore, behavioralSignals);

15

16 if (combinedScore.confidence > this.confidenceThreshold) {

17 await this.policyEngine.evaluate('fraud-alert', combinedScore);

18 return { flagged: true, score: combinedScore, action: 'review' };

19 }

20

21 return { flagged: false, score: combinedScore, action: 'pass' };

22 }

23}

Context Memory

Related Files

risk-scoring.ts

transaction-validator.ts

policy-engine.ts

Architecture Notes

Fraud detection uses a two-stage pipeline

Risk scoring feeds into behavioral analysis

Policy engine gates all alert dispatches

Past Decisions

Switched from threshold-only to combined scoring (v2.3)

Added behavioral signals in sprint 47

Confidence threshold raised from 0.75 to 0.85

PR Feedback

"Consider adding rate limiting" — @sarah

"Good separation of concerns" — @alex

"Add integration test for edge cases" — @mike

Governed code actions

Every suggestion passes capability checks defined by PlantoOS policies.

Coding Assistant›Workflow›Task #2,847

Step 3 of 4

Task: Implement fraud detection rule

Add device fingerprint validation to the fraud detection pipeline

Auto-discovered: 3 existing rules·Estimated: 4 steps·Started 45s ago

Agent Plan

1. Scan repository for existing fraud rulesComplete12s

Found 3 rule files in /src/rules/ — velocity-check.ts, amount-threshold.ts, geo-anomaly.ts

velocity-check.tsamount-threshold.tsgeo-anomaly.ts

2. Retrieve rule patterns from memoryComplete3s

Loaded 5 pattern templates from context memory — rule structure, validation schema, test fixtures

rule-template.tsvalidation.schema.ts

3. Generate validation logic for new ruleIn Progress

Generating device-fingerprint validation rule based on retrieved patterns and existing rule conventions

device-fingerprint.ts (generating)

4. Create unit and integration testsPending

Will generate test cases covering: valid transactions, flagged transactions, edge cases, concurrent processing

device-fingerprint.test.ts

Context Sources

Rule patterns (Memory)Project structure (Indexed)Test conventions (Memory)PR #1,392 feedback

Progress

75%

Traceable suggestions

Every generated change includes full lineage from prompt to commit.

Coding Assistant›Trace›Suggestion #5,291

All tests pass

Suggestion Traceability

Full lineage from prompt to commit

Prompt

Reasoning

Files Changed

Tests Generated

Commit Suggestion

Prompt

Add a device fingerprint validation rule to detect fraud based on device change patterns. Should follow existing rule conventions and include tests.

Reasoning

Analyzed 3 existing rules for conventions. Device fingerprint rule requires: hash comparison, geo-correlation, velocity check on device changes. Using the same RuleBase interface and policy integration pattern.

Pattern: existing rules use RuleBase abstract class

Validation: multi-signal approach (hash + geo + velocity)

Testing: mirror structure of velocity-check.test.ts

Policy: integrate with existing fraud-alert policy gate

Files Changed

src/rules/device-fingerprint.ts

Created+87

src/services/fraud-detection.ts

Modified+4 −1

src/config/rule-registry.ts

Modified+2

Tests Generated

should flag transaction with new device fingerprint

should allow known device with matching geo

should detect rapid device switching pattern

should handle missing fingerprint gracefully

should respect confidence threshold from config

Commit Suggestion

feat(fraud): add device fingerprint validation rule

Implements device fingerprint tracking and validation for the fraud detection pipeline. Uses multi-signal approach combining hash comparison, geo-correlation, and device change velocity.

feature/device-fingerprint-rule3 files+93−1

Policy-bound agents

Capability enforcement ensures autonomous systems operate within explicit boundaries.

Governance Flow

Policy-bound agent execution ensures autonomous systems operate within boundaries.

PlantoOS Policy Layer

Agents

Capability Policies

Approved Tools

Enterprise Systems

Denied — blocked by policy

Policy Layer

Agents

Capability Policies

Approved Tools

Enterprise Systems

Denied — policy block

Autonomous systems require explicit boundaries.

Where it sits in the stack

PlantoOS Architecture

The stack relationship between apps, agents, runtime, and systems.

Applications

Products and workflows

Agents

LLM-powered autonomous units

executionorchestrationcontrol

PlantoOS Runtime

Execution · orchestration · control

Capability Layer

Policy enforcement and tool access

memorygovernancelineage

Medhara Core

Memory · governance · lineage

Enterprise + Public Systems

Databases, APIs, infrastructure

A new compute layer for systems operated by agents.

Key workflows

How data flows through the system in typical usage patterns.

Workflow 1

Input

Developer asks for code suggestion

Core Process

Recalls repo context + past decisions + team patterns

Output

Contextually accurate suggestion with provenance link

Workflow 2

Input

Code action requested (refactor, generate, fix)

Core Process

Policy engine validates scope and capability boundaries

Output

Governed action with full lineage from context to output

Workflow 3

Input

PR submitted with AI-assisted code

Core Process

Lineage attached: which memories and policies informed the change

Output

Audit-ready PR metadata for review and compliance

Measured outcomes

↑ 25–40%

PR throughput improvement

↓ 30–50%

Context re-explaining reduced

↓ 20–35%

Faster issue resolution

Indicative ranges from internal benchmarks and early deployments; results vary by workload, model, and infrastructure.

How it integrates

SDK-first integration — governed from the first line of code.

1

Connect repo

Link your repository to the Medhara-powered assistant

2

Configure policies

Define what the assistant can read, write, and suggest

3

Start coding

Use in your IDE — context persists across sessions

example

// IDE extension connects to Medhara
// Context persists across sessions automatically

// The assistant remembers:
// - Your architectural decisions
// - Past PR feedback patterns
// - Team coding conventions
// - Repo-specific domain knowledge

// Every suggestion includes:
// - Source context references
// - Policy version that governed it
// - Lineage ID for audit trails